Re: Fast COPY FROM based on batch insert - Mailing list pgsql-hackers

From Etsuro Fujita
Subject Re: Fast COPY FROM based on batch insert
Date
Msg-id CAPmGK14XGLHKBfr639Y96X0LwWXzX+73oj=USRx7N2FC5FNVnQ@mail.gmail.com
Whole thread Raw
In response to Re: Fast COPY FROM based on batch insert  (Andrey Lepikhov <a.lepikhov@postgrespro.ru>)
Responses Re: Fast COPY FROM based on batch insert  (Etsuro Fujita <etsuro.fujita@gmail.com>)
List pgsql-hackers
On Thu, Oct 13, 2022 at 1:38 PM Andrey Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
> On 10/12/22 07:56, Etsuro Fujita wrote:
> > On Tue, Oct 11, 2022 at 3:06 PM Andrey Lepikhov
> > <a.lepikhov@postgrespro.ru> wrote:
> >> I reviewed the patch one more time. Only one question: bistate and
> >> ri_FdwRoutine are strongly bounded. Maybe to add some assertion on
> >> (ri_FdwRoutine XOR bistate) ? Just to prevent possible errors in future.
> >
> > You mean the bistate member of CopyMultiInsertBuffer?
> Yes
> >
> > We do not use that member at all for foreign tables, so the patch
> > avoids initializing that member in CopyMultiInsertBufferInit() when
> > called for a foreign table.  So we have bistate = NULL for foreign
> > tables (and bistate != NULL for plain tables), as you mentioned above.
> > I think it is a good idea to add such assertions.  How about adding
> > them to CopyMultiInsertBufferFlush() and
> > CopyMultiInsertBufferCleanup() like the attached?  In the attached I
> > updated comments a bit further as well.
> Yes, quite enough.

I have committed the patch after tweaking comments a little bit further.

Best regards,
Etsuro Fujita



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: archive modules
Next
From: Bharath Rupireddy
Date:
Subject: Re: Suppressing useless wakeups in walreceiver