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 CU78T23Z2OHU.37TFFFKMUGXU@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 19, 2023 at 10:07 PM CDT, Michael Paquier wrote:
> So this patch causes pgbench to not stick with its historical
> behavior, and the change is incompatible with the comments because the
> tellers and branches tables don't use NULL for their filler attribute
> anymore.

Great find. This was a problem of me just not understanding the COPY
command properly. Relevant documentation snippet:

> Specifies the string that represents a null value. The default is \N
> (backslash-N) in text format, and an unquoted empty string in CSV
> format. You might prefer an empty string even in text format for cases
> where you don't want to distinguish nulls from empty strings. This
> option is not allowed when using binary format.

This new revision populates the column with the NULL value.

> psql (17devel)
> Type "help" for help.
>
> tristan957=# select count(1) from pgbench_branches;
>  count
> -------
>      1
> (1 row)
>
> tristan957=# select count(1) from pgbench_branches where filler is null;
>  count
> -------
>      1
> (1 row)

Thanks for your testing Michael. I went ahead and added a test to make
sure that this behavior doesn't regress accidentally, but I am
struggling to get the test to fail using the previous version of this
patch. Do you have any advice? This is my first time writing a test for
Postgres. I can recreate the issue outside of the test script, but not
within it for whatever reason.

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

Attachment

pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Inefficiency in parallel pg_restore with many tables
Next
From: Farias de Oliveira
Date:
Subject: Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry?