On 2014-11-13 11:41:18 -0500, Robert Haas wrote: > On Wed, Nov 12, 2014 at 7:31 PM, Andres Freund <and...@2ndquadrant.com> wrote: > > But I think it won't work realistically. We have a *lot* of > > infrastructure that refers to indexes using it's primary key. I don't > > think we want to touch all those places to also disambiguate on some > > other factor. All the relevant APIs are either just passing around oids > > or relcache entries. > > I'm not quite following this. The whole point is to AVOID having two > indexes. You have one index which may at times have two sets of > physical storage.
Right. But how are we going to refer to these different relfilenodes? All the indexing infrastructure just uses oids and/or Relation pointers to refer to the index. How would you hand down the knowledge which of the relfilenodes is supposed to be used in some callchain? There's ugly solutions like having a flag like 'bool rd_useotherfilenode' inside struct RelationData, but even ignoring the uglyness I don't think that'd work well - what if some function called inside the index code again starts a index lookup? I think I might just not getting your idea here? > > And all the > > indexing infrastructure can't deal with that without having separate > > oids & relcache entries. Hopefully explained above? Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
