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 involve
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 fact
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 good
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.
