Re: [HACKERS] Proposal: Local indexes for partitioned table

From: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Maksim Milyutin <milyutinma(at)gmail(dot)com>
Subject: Re: [HACKERS] Proposal: Local indexes for partitioned table
Date: 2017-12-17 10:29:10
Message-ID: CAKJS1f8BR=gERRTZ-Vh-unTjUx7n4MD-KnYJ1pqcGfJUZG2TQA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 17 December 2017 at 16:22, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Fri, Dec 15, 2017 at 5:18 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>> We have two options for marking valid:
>>
>> 1. after each ALTER INDEX ATTACH, verify whether the set of partitions
>> that contain the index is complete; if so, mark it valid, otherwise do
>> nothing. This sucks because we have to check that over and over for
>> every index that we attach
>>
>> 2. We invent yet another command, say
>> ALTER INDEX <idx-on-parent> VALIDATE

It's not perfect that we need to validate each time, but it might not
be that expensive to validate since we only really need to count the
pg_index rows that have indisvalid = true rows which have a parent
index listed as the index we're ATTACHing too, then ensure that
matches the number of leaf partitions.

> If ALTER INDEX .. ATTACH is already taking AEL on the parent, then I
> think it might as well try to validate while it's at it. But if not
> then we might want to go with #2.

I'm now not that clear on what the behaviour is if the ONLY keyword is
not specified on the CREATE INDEX for the partitioned index. Does that
go and create each leaf partition index regardless of if there is a
suitable candidate to ATTACH?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-12-17 10:46:17 Re: PostgreSQL crashes with SIGSEGV
Previous Message Michael Paquier 2017-12-17 07:00:31 Re: pgsql: Provide overflow safe integer math inline functions.