On Fri, Nov 14, 2014 at 11:47 AM, Andres Freund <and...@2ndquadrant.com> wrote: > 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?
If you've got a Relation, you don't need someone to tell you which physical storage to use; you can figure that out for yourself by looking at the Relation. If you've got an OID, you're probably going to go conjure up a Relation, and then you can do the same thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
