On 18 August 2017 at 15:40, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > Ildar Musin wrote: > >> 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: > > I've been playing with the index code in order to allow indirect tuples, > which are stored in a format different from IndexTupleData. > > I've been adding an "InMemoryIndexTuple" (maybe there's a better name) > which internally has pointers to both IndexTupleData and > IndirectIndexTupleData, which makes it easier to pass around the index > tuple in either format.
> It's very easy to add an OID to that struct, > which then allows to include the OID in either an indirect index tuple > or a regular one. If there is a unique index then there is no need for that. Additional data to the index makes it even bigger and even less useful, so we need to count that as a further disadvantage of global indexes. I have a very clear statement from a customer recently that "We will never use global indexes", based upon their absolute uselessness in Oracle. > Then, wherever we're using IndexTupleData in the index AM code, we would > replace it with InMemoryIndexTuple. This should satisfy both your use > case and mine. Global indexes are a subset of indirect indexes use case but luckily not the only use. -- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
