Hi hackers,

While we've been developing pg_pathman extension one of the most frequent questions we got from our users was about global index support. We cannot provide it within an extension. And I couldn't find any recent discussion about someone implementing it. So I'm thinking about giving it a shot and start working on a patch for postgres.

One possible solution is to create an extended version of item pointer which would store relation oid along with block number and position:

struct ItemPointerExt
Oid ip_relid;
BlockIdData ip_blkid;
OffsetNumber ip_posid;

and use it in global index (regular index will still use old version). This will require in-depth refactoring of existing index nodes to make them support both versions. Accordingly, we could replace ItemPointer with ItemPointerExt in index AM to make unified API to access both regular and global indexes. TIDBitmap will require refactoring as well to be able to deal with relation oids.

It seems to be quite an invasive patch since it requires changes in general index routines, existing index nodes, catalog, vacuum routines and syntax. So I'm planning to implement it step by step. As a first prototype it could be:

* refactoring of btree index to be able to store both regular and extended item pointers;
* refactoring of TIDBitmap;
* refactoring of general index routines (index_insert, index_getnext, etc) and indexAM api; * catalog (add pg_index.indisglobal attribute and/or a specific relkind as discussed in [1] thread);
* syntax for global index definition. E.g., it could be oracle-like syntax:

        CREATE INDEX my_idx ON my_tbl (key) GLOBAL;

If it goes well, then I’ll do the rest of indexes and vacuuming. If you have any ideas or concerns I’ll be glad to hear it.

[1] https://www.postgresql.org/message-id/c8fe4f6b-ff46-aae0-89e3-e936a35f0cfd%40postgrespro.ru


Ildar Musin

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to