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
