MIME-Version: 1.0
References: <CAMT0RQR1TNSnSWwd65is=HCDjiP4i25mcDDoctEBEiV8351cMQ@mail.gmail.com>
 <20230814150737.GA1395427@nathanxps13> <d01513e9-8c19-da5-fabc-845f75377f52@mines-paristech.fr>
 <20230815153423.GB2296544@nathanxps13> <CA+TgmoaO+ZddJg=rSPra8ufpbufoZVKc-juW=9VDLd7Mam2RvQ@mail.gmail.com>
In-Reply-To: <CA+TgmoaO+ZddJg=rSPra8ufpbufoZVKc-juW=9VDLd7Mam2RvQ@mail.gmail.com>
From: Hannu Krosing <hannuk@google.com>
Date: Sat, 3 Feb 2024 08:54:16 +0100
Message-ID: <CAMT0RQQDHK1=PetcQ8vTLBi9T5a1KzfbbomBN1VcyRiSrD-NoQ@mail.gmail.com>
Subject: Re: pgbench - adding pl/pgsql versions of tests
To: Robert Haas <robertmhaas@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Fabien COELHO <coelho@cri.ensmp.fr>, 
	pgsql-hackers <pgsql-hackers@postgresql.org>, Dimitri Fontaine <dim@tapoueh.org>
Content-Type: multipart/alternative; boundary="000000000000c91b0b0610758928"
Archived-At: <https://www.postgresql.org/message-id/CAMT0RQQDHK1%3DPetcQ8vTLBi9T5a1KzfbbomBN1VcyRiSrD-NoQ%40mail.gmail.com>
Precedence: bulk

--000000000000c91b0b0610758928
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

My justification for adding pl/pgsql tests as part of the immediately
available tests is that pl/pgsql itself is always enabled, so having a
no-effort way to test its performance benefits would be really helpful.
We also should have "tps-b-like as SQL function" to round up the "test
what's available in server" set.

---
Hannu

On Fri, Feb 2, 2024 at 9:44=E2=80=AFPM Robert Haas <robertmhaas@gmail.com> =
wrote:

> On Tue, Aug 15, 2023 at 11:41=E2=80=AFAM Nathan Bossart
> <nathandbossart@gmail.com> wrote:
> > Why's that?  I'm not aware of any project policy that prohibits such
> > enhancements to pgbench.  It might take some effort to gather consensus
> on
> > a proposal like this, but IMHO that doesn't mean we shouldn't try.  If
> the
> > prevailing wisdom is that we shouldn't add more built-in scripts becaus=
e
> > there is an existing way to provide custom ones, then it's not clear th=
at
> > we should proceed with $SUBJECT, anyway.
>
> I don't think there's a policy against adding more built-in scripts to
> pgbench, but I'm skeptical of such efforts because I don't see how to
> decide which ones are worthy of inclusion and which are not. Adding
> everyone's favorite thing will be too cluttered, and adding nothing
> forecloses nothing because people can always provide their own. If we
> could establish that certain custom scripts are widely used across
> many people, then those might be worth adding.
>
> I have a vague recollection of someone proposing something similar to
> this in the past, possibly Jeff Davis. If there is in fact a paper
> trail showing that the same thing has been proposed more than once by
> unrelated people, that would be a point in favor of adding that
> particular thing.
>
> --
> Robert Haas
> EDB: http://www.enterprisedb.com
>

--000000000000c91b0b0610758928
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">My justification for adding pl/pgsql tests as part of the =
immediately available tests is that pl/pgsql itself is always enabled, so h=
aving a no-effort way to test its performance benefits would be really help=
ful.<br>We also should have &quot;tps-b-like as SQL function&quot; to round=
 up the &quot;test what&#39;s available in server&quot; set.<br><div><br>--=
-<br>Hannu</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=
=3D"gmail_attr">On Fri, Feb 2, 2024 at 9:44=E2=80=AFPM Robert Haas &lt;<a h=
ref=3D"mailto:robertmhaas@gmail.com">robertmhaas@gmail.com</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Aug 15, 2=
023 at 11:41=E2=80=AFAM Nathan Bossart<br>
&lt;<a href=3D"mailto:nathandbossart@gmail.com" target=3D"_blank">nathandbo=
ssart@gmail.com</a>&gt; wrote:<br>
&gt; Why&#39;s that?=C2=A0 I&#39;m not aware of any project policy that pro=
hibits such<br>
&gt; enhancements to pgbench.=C2=A0 It might take some effort to gather con=
sensus on<br>
&gt; a proposal like this, but IMHO that doesn&#39;t mean we shouldn&#39;t =
try.=C2=A0 If the<br>
&gt; prevailing wisdom is that we shouldn&#39;t add more built-in scripts b=
ecause<br>
&gt; there is an existing way to provide custom ones, then it&#39;s not cle=
ar that<br>
&gt; we should proceed with $SUBJECT, anyway.<br>
<br>
I don&#39;t think there&#39;s a policy against adding more built-in scripts=
 to<br>
pgbench, but I&#39;m skeptical of such efforts because I don&#39;t see how =
to<br>
decide which ones are worthy of inclusion and which are not. Adding<br>
everyone&#39;s favorite thing will be too cluttered, and adding nothing<br>
forecloses nothing because people can always provide their own. If we<br>
could establish that certain custom scripts are widely used across<br>
many people, then those might be worth adding.<br>
<br>
I have a vague recollection of someone proposing something similar to<br>
this in the past, possibly Jeff Davis. If there is in fact a paper<br>
trail showing that the same thing has been proposed more than once by<br>
unrelated people, that would be a point in favor of adding that<br>
particular thing.<br>
<br>
-- <br>
Robert Haas<br>
EDB: <a href=3D"http://www.enterprisedb.com" rel=3D"noreferrer" target=3D"_=
blank">http://www.enterprisedb.com</a><br>
</blockquote></div>

--000000000000c91b0b0610758928--