Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal)

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal)
Date: 2018-09-28 03:12:59
Message-ID: 20180928031259.GD1500@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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/

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>
--
Michael

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-09-28 03:17:00 Re: Segfault when creating partition with a primary key and sql_drop trigger exists
Previous Message Kato, Sho 2018-09-28 03:08:40 RE: Performance of the partitioning in the large scale