"David G. Johnston" <david.g.johns...@gmail.com> writes:
> Maybe consider writing a full patch series that culminates with this
> additional builtin option being added as the final patch - breaking out
> this (and probably other) "requirements" patches separately to aid in
> review. The presentation of just "add new stuff that seems useful" opens
> too much room for isolated discussion without knowing what the big picture
> requires. At worse you'll at least have a working version of a forked
> pgbench that can do what you want.
> As it stands right now you haven't provided enough context for this patch
> and only the social difficulty of actually marking a patch rejected has
> prevented its demise in its current form - because while it has interesting
> ideas its added maintenance burden for -core without any in-core usage.
> But it you make it the first patch in a 3-patch series that implements the
> per-spec tpc-b the discussion moves away from these support functions and
> into the broader framework in which they are made useful.
I think Fabien already did post something of the sort, or at least
discussion towards it, and there was immediately objection as to whether
his idea of TPC-B compliance was actually right. I remember complaining
that he had a totally artificial idea of what "fetching a data value"
requires. So a full patch series would be a good idea in that we could
discuss whether the requirements are correct before we get into the nitty
gritty of implementing them.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
