From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Robert Haas <robertmhaas(at)gmail(dot)com>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Custom table AMs need to include heapam.h because of BulkInsertState |
Date: | 2019-07-03 07:34:54 |
Message-ID: | 20190703073454.GF3084@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | David Rowley | 2019-07-03 07:46:06 | Re: Custom table AMs need to include heapam.h because of BulkInsertState |
Previous Message | David Rowley | 2019-07-03 07:34:03 | Re: Run-time pruning for ModifyTable |