Re: [PATCH] Refactor pgbench to make future improvements easier

The prliminary gap analysis for what is needed in pgbench to support
TPC and CH-benCHmark style workloads is in
https://wiki.postgresql.org/wiki/Pgbench-for-tpc-like-benchmarks

On Sun, Oct 4, 2026 at 11:17 AM Hannu Krosing <hannuk(at)google(dot)com> wrote:
>
> Hi Zsolt,
>
> Thanks for reviewing this
>
> Sorry for leaving more changes in than absolutely needed.
>
> This was extracted back from a more invasive set of patches that
>
> * extracts the various random distributions and other functions from
> pgbench language and making them available as an in-database extension
> https://commitfest.postgresql.org/patch/7225/
>
> * adds a few more functions and language constructs to make it easier
> to write TPC-* - like benchmarks
>
> Would it make it easier for you to review if I reworked this set to
> strictly move functions between source files, or are you still able to
> review this as it is?
>
> Best Regards
>
> Hannu
>
> On Sun, Oct 4, 2026 at 12:20 AM Zsolt Parragi <zsolt(dot)parragi(at)percona(dot)com> wrote:
> >
> > Hello!
> >
> > From the email explaining that this is a split, and the commit
> > messages saying "extract" I expected a move-only patchset that
> > strictly extracts part of the code into different files/modules. But
> > that doesn't seem to be the case?
> >
> > For example "executeMetaCommand" looks completely different in the
> > end, chooseScript and other functions got signature changes, the
> > number of comment lines got reduces by ~25%, a VariableScopeStack
> > typedef is introduced that isn't used anywhere, etc.
> >
> > I think for something like this to be easily reviewable, moves and
> > logic changes should be strictly separate patches, not mixed together,
> > and anything that's not a simple cut-and-paste into another file
> > should be mentioned. In the current patchset, 0007 seems to be the
> > closest to a pure move, but even that isn't just that. (When I am
> > doing something similar, I usually follow a one refactoring - one
> > commit/patch approach during the review, only squashing things
> > together later)
> >
> > I also checked the commit history of pgbench, it seems to get around
> > ~4 backpatched commits per year, so that doesn't seem to be that bad
> > through a refactoring.