Re: Proposal: Local indexes for partitioned table

From: Maksim Milyutin <m(dot)milyutin(at)postgrespro(dot)ru>
To: 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-17 14:00:32
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 10.04.2017 14:20, Robert Haas wrote:
> On Tue, Apr 4, 2017 at 12:10 PM, Maksim Milyutin
> <m(dot)milyutin(at)postgrespro(dot)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:
Russian Postgres Company

Attachment Content-Type Size
local_index_without_new_relkind.patch text/x-patch 11.6 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-04-17 14:08:20 Re: Logical replication and inheritance
Previous Message Stas Kelvich 2017-04-17 13:59:35 Re: Logical replication - TRAP: FailedAssertion in pgstat.c