On Tue, Apr 18, 2017 at 4:43 PM, Maksim Milyutin <m.milyu...@postgrespro.ru> wrote: > 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 */
An index on partitioned table can be global index (yet to be implemented) or a local index. We can not differentiate between those just by looking at the relation on which they are built. > >> 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. > A global index would have storage for a partitioned table whereas a local index wouldn't have any storage for a partitioned table. I agree with Amit that we need new relkinds for local as well as global indexes. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers