Re: pgbench more operators & functions

* Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> Stephen Frost <sfrost(at)snowman(dot)net> writes:
> > * Tom Lane (tgl(at)sss(dot)pgh(dot)pa(dot)us) wrote:
> >> It already is a script, it's just hardwired as a string constant in
> >> pgbench.c rather than being a separate file. I think Fabien is
> >> suggesting that it could be changed to more nearly approximate the
> >> actual TPC-B spec, but IMO that would be a seriously bad idea because
> >> it would invalidate all cross-version performance comparisons. We
> >> decided years ago that the default script is what it is and we aren't
> >> going to change it to try to match TPC-B more exactly.
>
> > If we could replicate what the hardwired script does in an external
> > script, keeping that as the default, and then provide a 'Closer to
> > TPC-B' script, then I'm all for that.
>
> I've got no objection to a more-nearly-TPC-B script as an option.
> But why do you feel the need to pull the default script out into
> a separate file? Seems to me that just adds maintenance complexity,
> and the need for pgbench to have a notion of a library directory,
> for little gain.

Part of it is a feeling that we should really be 'eating our own
dogfood' when it comes to pgbench, but also that it seems to add
unnecessary C-level code to an otherwise general-purpose utility
for no particular reason except "that's how it was first written."

Perhaps that's overkill for this case and you have an interesting point
that it might require additional code in pgbench (though I'm not
completely convinced of that...), so I won't push too hard on it, but I
still think it'd be "better" to have pgbench just be the general purpose
utility and not also have some built-in thing, even if it's obvious that
it could just be a script.

Thanks!

Stephen