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/
