Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal) - Mailing list pgsql-hackers

From David Rowley
Subject Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal)
Date
Msg-id CAKJS1f-Tom777tf=5yRrTd_UbfPhi3OxOQbkrmTYOdb+t0wabw@mail.gmail.com
Whole thread Raw
In response to heap_sync seems rather oblivious to partitioned tables(wal_level=minimal)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: heap_sync seems rather oblivious to partitioned tables(wal_level=minimal)  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
On 19 September 2018 at 12:21, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> So apparently CopyFrom() invokes heap_sync() on the partitioned
> relation, which attempts to do mdimmedsync() only on the root. That
> seems like a bug to me.
>
> Obviously this only applies to wal_level=minimal. There are multiple
> callers of heap_sync(), but only the COPY seems to be affected by this,
> because the rest can't see partitioned tables.
>
> So it seems heap_sync() needs to be improved to sync all partitions.

Wouldn't it be better to modify copy.c to just perform the heap_sync
on just the partitions it touches?

After https://commitfest.postgresql.org/19/1690/ it's very efficient
to know which partitions were used. The bulk load might just be
hitting a single partition, so it makes sense to try to just do the
ones we need to, rather than needlessly performing heap_sync() on all
of them.

For the back branches, the current form of PartitionDispatch is not
particularly inefficient to just skip over the uninitialized
partitions.

6b78231d918 did recently just make the PartitionDispatch struct's
members private to execPartition.c, so doing this will probably
require some API function that can be passed a callback function to do
what we need.

-- 
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services


pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: incorrect comment or possible lock upgrade hazards in executor
Next
From: Stephen Frost
Date:
Subject: Re: Collation versioning