Re: Support for REINDEX CONCURRENTLY

On Tue, Feb 12, 2013 at 10:04 PM, Andres Freund <andres@2ndquadrant.com>wrote:

> On 2013-02-12 21:54:52 +0900, Michael Paquier wrote:
> > > Changing only toast_save_datum:
> > >
> > > [... code ...]
> > >
> > Yes, I have spent a little bit of time looking at the code related to
> > retoastindxid and thought about this possibility. It would make the
> changes
> > far easier with the existing patch, it will also be necessary to update
> the
> > catalog pg_statio_all_tables to make the case where OID is InvalidOid
> > correct with this catalog.
>
> What I proposed above wouldn't need the case where toastrelidx =
> InvalidOid, so no need to worry about that.
>
[re-reading code...] Oh ok. I missed the point in your previous email. Yeah
indeed you are right.


>
> > However, I do not think it is as clean as simply
> > removing retoastindxid and have all the toast APIs running consistent
> > operations, aka using only RelationGetIndexList.
>
> Sure. This just seems easier as it really only requires changes inside
> toast_save_datum() and which mostly avoids any overhead (not even
> additional palloc()s) if there is only one index.
> That would lower the burden of proof that no performance regressions
> exist (which I guess would be during querying) and the amount of
> possibly external breakage due to removing the field...
>
> Not sure whats the best way to do this when committing. But I think you
> could incorporate something like the proposed to continue working on the
> patch. It really should only take some minutes to incorporate it.
>

OK I'll add the changes you are proposing. I still want to have a look at
the approach for the removal of reltoastidxid btw.
-- 
Michael