Re: [HACKERS] Proposal: global index

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: [HACKERS] Proposal: global index
Дата
Msg-id CAN-RpxDux_TWw4Q3Bx9T7Wr9euw4_WsJHVw7iW3QEFjD3Y9axg@mail.gmail.com
обсуждение исходный текст
Ответ на [HACKERS] Proposal: global index  (Ildar Musin <i.musin@postgrespro.ru>)
Ответы Re: [HACKERS] Proposal: global index  (Ildar Musin <i.musin@postgrespro.ru>)
Список pgsql-hackers
I would really like to see global indexes.  It would make things a lot easier for things like unique constraints across table inheritance trees.  

On Fri, Aug 18, 2017 at 11:12 AM, Ildar Musin <i.musin@postgrespro.ru> wrote:
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.

So, to be clear on-disk representations would be unchanged for old indexes (ensuring that pg_upgrade would not be broken), right? 

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;

Do you foresee any performance implementation of handling both?
 
 
* 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.musin@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



--
Best Regards,
Chris Travers
Database Administrator

Tel: +49 162 9037 210 | Skype: einhverfr | www.adjust.com 
Saarbrücker Straße 37a, 10405 Berlin

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Aleksandr Parfenov
Дата:
Сообщение: [HACKERS] [PROPOSAL] Text search configuration extension
Следующее
От: David Fetter
Дата:
Сообщение: Re: [HACKERS] Add support for tuple routing to foreign partitions