On 28 September 2018 at 15:12, Michael Paquier <michael@paquier.xyz> wrote:
> On Fri, Sep 28, 2018 at 02:46:30PM +1200, David Rowley wrote:
>> I don't agree that we can skip explaining why one of the optimisations
>> can't be applied just because we've explained why a similar
>> optimisation cannot be applied somewhere close by. I think that the
>> WAL/FSM optimisation can fairly easily be improved on and probably
>> fixed in PG12 as we can just lazily determine per-partition if it can
>> be applied to that partition or not.
>
> Have you guys looked at what the following patch does for partitions and
> how it interacts with it?
> https://commitfest.postgresql.org/19/528/
I've glanced at it. I don't think we're taking anything in the wrong
direction. The patch looks like it would need rebased if this gets in
first.
> The proposed patch is missing the point that documentation also mentions
> the optimizations for COPY with wal_level = minimal:
> <para>
> <command>COPY</command> is fastest when used within the same
> transaction as an earlier <command>CREATE TABLE</command> or
> <command>TRUNCATE</command> command. In such cases no WAL
> needs to be written, because in case of an error, the files
> containing the newly loaded data will be removed anyway.
> However, this consideration only applies when
> <xref linkend="guc-wal-level"/> is <literal>minimal</literal> as all commands
> must write WAL otherwise.
> </para>
I've edited that in the attached patch. Also reworded a comment that
Amit mentioned and made a small change to the COPY FREEZE docs to
mention no support for partitioned tables.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services