| From: | "Tristan Partin" <tristan(at)neon(dot)tech> | 
|---|---|
| To: | "Michael Paquier" <michael(at)paquier(dot)xyz> | 
| Cc: | <pgsql-hackers(at)postgresql(dot)org> | 
| Subject: | Re: Use COPY for populating all pgbench tables | 
| Date: | 2023-07-20 19:22:51 | 
| Message-ID: | CU78T23Z2OHU.37TFFFKMUGXU@gonk | 
| Views: | Whole Thread | Raw Message | Download mbox | Resend email | 
| Thread: | |
| Lists: | 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 | Content-Type | Size | 
|---|---|---|
| v6-0001-Use-COPY-instead-of-INSERT-for-populating-all-tab.patch | text/x-patch | 10.3 KB | 
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Farias de Oliveira | 2023-07-20 20:05:29 | Re: In Postgres 16 BETA, should the ParseNamespaceItem have the same index as it's RangeTableEntry? | 
| Previous Message | Nathan Bossart | 2023-07-20 19:06:44 | Re: Inefficiency in parallel pg_restore with many tables |