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

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: [HACKERS] Proposal: Local indexes for partitioned table
Дата
Msg-id CAKJS1f8BR=gERRTZ-Vh-unTjUx7n4MD-KnYJ1pqcGfJUZG2TQA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal: Local indexes for partitioned table  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Proposal: Local indexes for partitioned table  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 17 December 2017 at 16:22, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Dec 15, 2017 at 5:18 PM, Alvaro Herrera <alvherre@alvh.no-ip.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Protect syscache from bloating with negative cache entries
Следующее
От: Alvaro Hernandez
Дата:
Сообщение: Re: GSoC 2018