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 <robertmh...@gmail.com> wrote: > On Tue, Aug 15, 2023 at 11:41 AM Nathan Bossart > <nathandboss...@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. > > -- > Robert Haas > EDB: http://www.enterprisedb.com >
