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.
On Tue, Aug 15, 2023 at 11:41 AM 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 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.
