Re: Making "COPY partitioned_table FROM" faster - Mailing list pgsql-hackers

From Melanie Plageman
Subject Re: Making "COPY partitioned_table FROM" faster
Date
Msg-id CAAKRu_Y_+gCBQp4byL4N4Ac3-Us6698cSW=E1E59NtO85NiFYQ@mail.gmail.com
Whole thread Raw
In response to Re: Making "COPY partitioned_table FROM" faster  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers


On Mon, Jul 30, 2018 at 11:21 AM, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote:
On 30/07/2018 15:26, David Rowley wrote:
>> - Add some tests.  The if (nBufferedTuples > 0) that flushes the tuples
>> when the partition changes is not currently exercised.
>
> That seems like a good idea. In fact, it uncovered a bug around
> ConvertPartitionTupleSlot() freeing the previously stored tuple out
> the slot which resulted in a crash. I didn't notice before because my
> test had previously not required any tuple conversions.

I think we need to think of a better place to put that temporary file,
and clean it up properly afterwards.  I'm not sure whether we have
existing uses like that.

Also, maybe the test should check afterwards that the right count of
rows ended up in each partition?

Yea, I actually would suggest changing the data inserted in the third insert statement to have 'Three' in the third column:
insert into parted_copytest select x,1,'One' from generate_series(1011,1020) x;
And then this check:
select count(*) from parted_copytest group by a, b, c;


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Segfault logical replication PG 10.4
Next
From: Mai Peng
Date:
Subject: Re: Segfault logical replication PG 10.4