Re: REINDEX CONCURRENTLY 2.0

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.

> There's also the problem that we'd really need two different pg_index
> rows to make things work. Alternatively we can duplicate the three
> relevant columns (indisready, indislive, indislive) in there for the
> different filenodes. But that's not entirely pretty.

I think what you would probably end up with is a single "char" or int2
column that defines the state of the index. Certain states would be
valid only when relnewfilenode != 0.

>> 1. Take a snapshot.
>> 2. Index all the tuples in that snapshot.
>> 3. Publish the new relfilenode to an additional pg_class column,
>> relnewfilenode or similar.
>> 4. Wait until everyone can see step #3.
>
> Here all backends need to update both indexes, right?

Yes.

> And all the
> indexing infrastructure can't deal with that without having separate
> oids & relcache entries.

Why not?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company