From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: heap_sync seems rather oblivious to partitioned tables (wal_level=minimal) |
Date: | 2018-09-19 01:14:10 |
Message-ID: | CAKJS1f-Tom777tf=5yRrTd_UbfPhi3OxOQbkrmTYOdb+t0wabw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 19 September 2018 at 12:21, Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2018-09-19 01:16:07 | Re: Collation versioning |
Previous Message | David Rowley | 2018-09-19 00:59:38 | incorrect comment or possible lock upgrade hazards in executor |