| From: | "Koshi Shibagaki (Fujitsu)" <shibagaki(dot)koshi(at)fujitsu(dot)com> |
|---|---|
| To: | Mircea Cadariu <cadariu(dot)mircea(at)gmail(dot)com> |
| Cc: | lakshmi <lakshmigcdac(at)gmail(dot)com>, "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "tomas(at)vondra(dot)me" <tomas(at)vondra(dot)me>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
| Subject: | Re: parallel data loading for pgbench -i |
| Date: | 2026-10-15 04:54:43 |
| Message-ID: | TY5PR01MB1844572BFA5210A6942B8DE03FA9C2@TY5PR01MB18445.jpnprd01.prod.outlook.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Mircea,
Thanks for v5. I confirmed that the three issues I reported have been fixed.
I noticed that parallel loading is enabled only when the t step precedes
the g step in the same invocation. For example:
pgbench -i -I dt -s 1 --partitions=4 postgres
pgbench -i -I g -s 2 -j 2 postgres
The second command succeeds, but loads the data serially despite -j 2.
Specifying --partitions=4 again does not enable parallel loading either,
because tables_created is false in the second invocation.
Would it make sense to read the partition count and bounds from the
existing pgbench_accounts table when running the g step? This could allow
parallel loading without repeating --partitions, while treating --scale
as the amount of data to generate.
Removing the tables_created check alone would not be enough: the first partition
accepts aid < 25001, but evenly dividing 200000 rows would send values
up to 50000 to it. Parallel loading needs to respect the existing partition bounds.
For partition layouts that parallel loading cannot handle, it might also
be helpful to fall back to serial loading with a message explaining why
-j is not being used.
Regards,
Koshi Shibagaki
FUJITSU LIMITED
https://www.fujitsu.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2026-10-15 04:55:02 | Re: Bug in logical decoding with DDL and subtransactions |
| Previous Message | shveta malik | 2026-10-15 04:17:28 | Re: Proposal: Conflict log history table for Logical Replication |