Re: expanding inheritance in partition bound order

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Amit Khandekar <amitdkhan(dot)pg(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: expanding inheritance in partition bound order
Date: 2017-08-30 16:11:06
Message-ID: CA+TgmoZsE7X6gv7+ewr64cCmvjnvrigZ3zdgxdPhdkYjKmK-+A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Aug 30, 2017 at 10:31 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Aug 30, 2017 at 9:22 AM, Ashutosh Bapat
> <ashutosh(dot)bapat(at)enterprisedb(dot)com> wrote:
>> Amit's patches seem to be addressing the third point here. But the
>> expansion is not happening in breadth-first manner. We are expanding
>> all the partitioned partitions first and then leaf partitions. So
>> that's not exactly "breadth-first".
>
> Correct, but I think Amit's ordering is what we actually want:
> breadth-first, low-OID-first over interior partitioned tables, and
> then breadth-first, low-OID-first again over leaves. If we don't keep
> partitioned partitions first, then we're going to have problems
> keeping the locking order consistent when we start doing pruning
> during expansion.

No, I'm wrong and you're correct. We want the partitions to be locked
first, but we don't want them to be pulled to the front of the
expansion order, because then it's not in bound order anymore and any
optimization that tries to rely on that ordering will break.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-08-30 16:12:56 Re: expanding inheritance in partition bound order
Previous Message Sokolov Yura 2017-08-30 15:50:05 Re: LWLock optimization for multicore Power machines