Re: Proposal: Local indexes for partitioned table

From: Maksim Milyutin <m(dot)milyutin(at)postgrespro(dot)ru>
To: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Proposal: Local indexes for partitioned table
Date: 2017-04-18 11:13:00
Message-ID: 385bc71c-53b4-a0cc-474d-e1b620061818@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 18.04.2017 13:08, Amit Langote wrote:
> Hi,
>

Hi, Amit!

> On 2017/04/17 23:00, Maksim Milyutin wrote:
>>
>> Ok, thanks for the note.
>>
>> But I want to discuss the relevancy of introduction of a new relkind for
>> partitioned index. I could to change the control flow in partitioned index
>> creation (specify conditional statement in the 'index_create' routine in
>> attached patch) and not enter to the 'heap_create' routine. This case
>> releases us from integrating new relkind into different places of Postgres
>> code. But we have to copy-paste some specific code from 'heap_create'
>> function, e.g., definition of relfilenode and tablespaceid for the new
>> index and perhaps something more when 'heap_create' routine will be extended.
>
> I may be missing something, but isn't it that a new relkind will be needed
> anyway? How does the rest of the code distinguish such index objects once
> they are created?

Local partitioned indexes can be recognized through the check on the
relkind of table to which the index refers. Something like this:

heap = relation_open(IndexGetRelation(indexid, false), heapLockmode);
if (heap->rd_rel->relkind == RELKIND_PARTITIONED_TABLE)
/* indexid is local index on partitioned table */

> Is it possible that some other code may try to access
> the storage for an index whose indrelid is a partitioned table?
>

Thеsе cases must be caught. But as much as partitioned tables doesn't
participate in query plans their indexes are unaccessible by executor.
Reindex operation is overloaded with my patch.

--
Maksim Milyutin
Postgres Professional: http://www.postgrespro.com
Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Stas Kelvich 2017-04-18 11:45:46 Logical replication ApplyContext bloat
Previous Message Ashutosh Bapat 2017-04-18 10:55:17 Re: Partition-wise join for join between (declaratively) partitioned tables