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

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.