Re: Custom table AMs need to include heapam.h because ofBulkInsertState - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Custom table AMs need to include heapam.h because ofBulkInsertState
Date
Msg-id 20190703073454.GF3084@paquier.xyz
Whole thread Raw
In response to Re: Custom table AMs need to include heapam.h because of BulkInsertState  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Custom table AMs need to include heapam.h because of BulkInsertState  (David Rowley <david.rowley@2ndquadrant.com>)
Re: Custom table AMs need to include heapam.h because of BulkInsertState  (David Rowley <david.rowley@2ndquadrant.com>)
List pgsql-hackers
On Tue, Jul 02, 2019 at 01:26:26AM +1200, David Rowley wrote:
> I've pushed the original patch plus a small change to only call
> table_finish_bulk_insert() for the target of the copy when we're using
> bulk inserts.

Yes, sorry for coming late at the party here.  What I meant previously
is that I did not find the version published at [1] to be natural with
its structure to define an executor callback which then calls a
callback for table AMs, still I get your point that it would be better
to try to avoid unnecessary fsync calls on partitions where no tuples
have been redirected with a COPY.  The version 1 of the patch attached
at [2] felt much more straight-forward and cleaner by keeping all the
table AM callbacks within copy.c.

This has been reverted as of f5db56f, still it seems to me that this
was moving in the right direction.

[1]: https://postgr.es/m/CAKJS1f95sB21LBF=1MCsEV+XLtA_JC3mtXx5kgDuHDsOGoWhKg@mail.gmail.com
[2]: https://postgr.es/m/CAKJS1f_0t-K0_3xe+erXPQ-jgaOb6tRZayErCXF2RpGdUVMt9g@mail.gmail.com
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Run-time pruning for ModifyTable
Next
From: David Rowley
Date:
Subject: Re: Custom table AMs need to include heapam.h because of BulkInsertState