Re: pgbench - adding pl/pgsql versions of tests

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 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Tue, Aug 15, 2023 at 11:41 AM Nathan Bossart
> <nathandbossart(at)gmail(dot)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 because
> > there is an existing way to provide custom ones, then it's not clear that
> > 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
>