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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
