RE: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY)

From: Madyshev Egor <E(dot)Madyshev(at)ftdata(dot)ru>
To: Boris Mironov <boris_mironov(at)outlook(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: RE: Idea to enhance pgbench by more modes to generate data (multi-TXNs, UNNEST, COPY BINARY)
Date: 2026-03-12 12:15:23
Message-ID: 4a3bfa370a7d48d1965b12572a0de0e5@localhost.localdomain
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Boris,

I've finished reviewing the latest v15 version of your patch, everything looks good.
- The patch is applied to the current version of the master branch.
- All check-world tests pass. The patch adds tests for the implemented functionality.
- The code conforms to the PostgreSQL coding style (verified by pgindent).
- The added functionality has been tested and works as expected.
- The added functionality does not violate the existing one.
- Difficult-to-understand code locations are properly commented.
- The documentation has been updated and is correct.

The patch adds two additional data generation modes to pgbench: SELECT unnest on the
server and COPY.. FROM BINARY on the client. As well as a setting that includes
adding data in multitransaction mode. This allows you to positively influence
performance at large --scale=. All this will also make it possible to implement
parallel data loading in several sessions in the future.
The unnest mode will be useful for columnar tables.

All of the above allows me to consider the patch ready for the committer.

I am updating the patch to the Ready for Committer status.

Best regards,
Egor

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Yura Sokolov 2026-03-12 12:22:35 Re: Why clearing the VM doesn't require registering vm buffer in wal record
Previous Message Greg Sabino Mullane 2026-03-12 12:10:53 Re: ALTER TABLE: warn when actions do not recurse to partitions