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
Thanks!
--
Ildar Musin
i.mu...@postgrespro.ru
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
