Hi,
On 2017/04/17 23:00, Maksim Milyutin wrote:
> 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.
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? Is it possible that some other code may try to access
the storage for an index whose indrelid is a partitioned table?
Thanks,
Amit
