"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 (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers