Horton

Re: Proposal: Local indexes for partitioned table

Maksim Milyutin <m.milyutin@postgrespro.ru>

View thread View on postgr.es
From: Maksim Milyutin <m.milyutin@postgrespro.ru>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-04-17T14:00:32Z
Lists: pgsql-hackers

Attachments

On 10.04.2017 14:20, Robert Haas wrote:
> On Tue, Apr 4, 2017 at 12:10 PM, Maksim Milyutin
> <m.milyutin@postgrespro.ru> wrote:
>> 1. I have added a new relkind for local indexes named RELKIND_LOCAL_INDEX
>> (literal 'l').
>
> Seems like it should maybe be RELKIND_PARTITIONED_INDEX.  There's
> nothing particularly "local" about it.  I suppose what you're going
> for is that it's not global, but in a way it *is* global to the
> partitioning hierarchy.  That's the point.  It's just that it's
> partitioned.
>

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.

What do you think about this way?


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

Commits

  1. Local partitioned indexes

  2. Fix StoreCatalogInheritance1 to use 32bit inhseqno

  3. Get rid of copy_partition_key

  4. Simplify index_[constraint_]create API