Re: Use COPY for populating all pgbench tables - Mailing list pgsql-hackers

From Tristan Partin
Subject Re: Use COPY for populating all pgbench tables
Date
Msg-id CU09K8PHEOIZ.I5NPQDPOQ1SO@gonk
Whole thread Raw
In response to Re: Use COPY for populating all pgbench tables  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Use COPY for populating all pgbench tables
List pgsql-hackers
On Wed Jul 12, 2023 at 1:06 AM CDT, Michael Paquier wrote:
> 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.

Perhaps, should they all be keyed off the same option? Seemed like in
your previous comment you wanted multiple options. Sorry for not reading
your comment correctly.

> 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.

I will amend the documentation to mention all tables rather than being
specific to pgbench_accounts in the next patch revision pending what you
want to do about the partition CLI argument.

--
Tristan Partin
Neon (https://neon.tech)



pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: tablecmds.c/MergeAttributes() cleanup
Next
From: Peter Eisentraut
Date:
Subject: Re: Clean up some signal usage mainly related to Windows