| From: | Boris Mironov <boris_mironov(at)outlook(dot)com> |
|---|---|
| To: | Madyshev Egor <E(dot)Madyshev(at)ftdata(dot)ru>, "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-03 04:06:30 |
| Message-ID: | PH0PR08MB70202953137489C2DE455005887FA@PH0PR08MB7020.namprd08.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Egor,
Thank you for your time reviewing this patch and all of its versions!
> 1. What do you think about moving characters in 'detail: Allowed step
> characters are: "dtgMScGUvpf"' so that generation modes and
> transactions count modes are not mixed? For example "dtMSgcGUvpf".
Done
> 2. In the initCreateTables function, default values are set as empty
> strings '' in the pgbench_history and pgbench_accounts tables. Was
> this done intentionally, and if so, what is the reason? In the
> pgbench_tellers and pgbench_branches tables, the implicit default
> would be NULL - why was this logic changed?
I personally would set default filler for every table since "TPC-B-like"
means that filler is not used as expected by actual requirement of
TPC-B for row length. There are 2 specific tests for not-NULL values
in those 2 tables that do not have "default values". I would prefer
to use similar approach everywhere and bring on requirement of TPC-B
for row length. Since TPC-B is kind of archaic now this isn't best
tactic to fight another battle against "well established test set".
> 3. In showPopulateTableCopyProgress, I think it would be better to
> calculate elapsed_sec and remaining_sec inside the condition blocks,
> as is done in the original code.
I believe original code with complete copy of both variables initialization
twice in the same proc doesn't bring any benefits. Hence shortened it.
> 4. Do the changes and bug fixes in the patch affect performance? Are
> the existing performance measurements still valid?
We didn't significantly alter logic since last benchmark. I'll try to find some
time to rerun all tests again and publish updated results.
Best regards,
Egor
| Attachment | Content-Type | Size |
|---|---|---|
| v10-pgbench-faster-modes.patch | application/octet-stream | 125.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Michael Paquier | 2026-03-03 04:13:11 | Re: [BUGFIX] Fix crash due to sizeof bug in RegisterExtensionExplainOption |
| Previous Message | Hayato Kuroda (Fujitsu) | 2026-03-03 04:02:53 | RE: BUG: Former primary node might stuck when started as a standby |