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. > 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
