Re: parallel data loading for pgbench -i

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/

In response to

Browse pgsql-hackers by date

  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