On Tue, Jul 11, 2023 at 09:46:43AM -0500, Tristan Partin wrote:
> On Tue Jul 11, 2023 at 12:03 AM CDT, Michael Paquier wrote:
>> This seems a bit incorrect because partitioning only applies to
>> pgbench_accounts, no? This change means that the teller and branch
>> tables would not benefit from FREEZE under a pgbench compiled with
>> this patch and a backend version of 14 or newer if --partitions is
>> used. So, perhaps "partitions" should be an argument of
>> initPopulateTable() specified for each table?
>
> Whoops, looks like I didn't read the comment for what the partitions
> variable means. It only applies to pgbench_accounts as you said. I don't
> think passing it in as an argument would make much sense. Let me know
> what you think about the change in this new version, which only hits the
> first portion of the `if` statement if the table is pgbench_accounts.
- /* use COPY with FREEZE on v14 and later without partitioning */
- if (partitions == 0 && PQserverVersion(con) >= 140000)
- copy_statement = "copy pgbench_accounts from stdin with (freeze on)";
+ if (partitions == 0 && strcmp(table, "pgbench_accounts") == 0 && PQserverVersion(con) >= 140000)
+ copy_statement_fmt = "copy %s from stdin with (freeze on)";
This would use the freeze option only on pgbench_accounts when no
partitioning is defined, but my point was a bit different. We could
use the FREEZE option on the teller and branch tables as well, no?
Okay, the impact is limited compared to accounts in terms of amount of
data loaded, but perhaps some people like playing with large scaling
factors where this could show a benefit in the initial data loading.
In passing, I have noticed the following sentence in pgbench.sgml:
Using <literal>g</literal> causes logging to print one message
every 100,000 rows while generating data for the
<structname>pgbench_accounts</structname> table.
It would become incorrect as the same code path would be used for the
teller and branch tables.
--
Michael