Re: REINDEX CONCURRENTLY 2.0

On Fri, Nov 14, 2014 at 11:47 AM, Andres Freund <andres(at)2ndquadrant(dot)com> wrote:
> On 2014-11-13 11:41:18 -0500, Robert Haas wrote:
>> On Wed, Nov 12, 2014 at 7:31 PM, Andres Freund <andres(at)2ndquadrant(dot)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