MIME-Version: 1.0
References: <CAMT0RQR1TNSnSWwd65is=HCDjiP4i25mcDDoctEBEiV8351cMQ@mail.gmail.com>
 <20230814150737.GA1395427@nathanxps13> <d01513e9-8c19-da5-fabc-845f75377f52@mines-paristech.fr>
 <20230815153423.GB2296544@nathanxps13> <52432287-b496-abd3-edc-4beddbc051f0@mines-paristech.fr>
In-Reply-To: <52432287-b496-abd3-edc-4beddbc051f0@mines-paristech.fr>
From: Hannu Krosing <hannuk@google.com>
Date: Fri, 18 Aug 2023 19:34:03 +0200
Message-ID: <CAMT0RQQj=85ohk5Ee_7v4=_7ZTdVWTYm0bDvp3iXiMZrV0q=6w@mail.gmail.com>
Subject: Re: pgbench - adding pl/pgsql versions of tests
To: Fabien COELHO <coelho@cri.ensmp.fr>
Cc: Nathan Bossart <nathandbossart@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, 
	Dimitri Fontaine <dim@tapoueh.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAMT0RQQj%3D85ohk5Ee_7v4%3D_7ZTdVWTYm0bDvp3iXiMZrV0q%3D6w%40mail.gmail.com>
Precedence: bulk

I will address the comments here over this coming weekend.


I think that in addition to current "tpc-b like" test we could also
have more modern "tpc-c like" and "tpc-h like" tests

And why not any other "* -like" from the rest of TPC-*, YCSP, sysbench, ...=
 :)

though maybe not as part of pg_bench but as extensions ?

---
Hannu

On Wed, Aug 16, 2023 at 10:06=E2=80=AFAM Fabien COELHO <coelho@cri.ensmp.fr=
> wrote:
>
>
> Hello Nathan,
>
> >> I'm unclear about what variety of scripts that could be provided given=
 the
> >> tables made available with pgbench. ISTM that other scenari would invo=
lve
> >> both an initialization and associated scripts, and any proposal would =
be
> >> bared because it would open the door to anything.
> >
> > Why's that?
>
> Just a wild guess based on 19 years of occasional contributions to pg and
> pgbench in particular:-)
>
> > I'm not aware of any project policy that prohibits such enhancements to
> > pgbench.
>
> Attempts in extending pgbench often fall under "you can do it outside (eg
> with a custom script) so there is no need to put that in pgbench as it
> would add to the maintenance burden with a weak benefit proven by the fac=
t
> that it is not there already".
>
> > It might take some effort to gather consensus on a proposal like this,
> > but IMHO that doesn't mean we shouldn't try.
>
> Done it in the past. Probably will do it again in the future:-)
>
> > If the prevailing wisdom is that we shouldn't add more built-in scripts
> > because there is an existing way to provide custom ones, then it's not
> > clear that we should proceed with $SUBJECT, anyway.
>
> I'm afraid there is that argument. I do not think that this policy is goo=
d
> wrt $SUBJECT, ISTM that having an easy way to test something with a
> PL/pgSQL function would help promote the language by advertising/showing
> the potential performance benefit (or not, depending). Just one function
> would be enough for that.
>
> --
> Fabien.