Re: Support for REINDEX CONCURRENTLY

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

> On 2013-02-07 17:28:53 +0900, Michael Paquier wrote:
> > On Thu, Feb 7, 2013 at 5:15 PM, Andres Freund <andres@2ndquadrant.com>wrote:
>
>
> Btw, I think that if this optimization for toast relations is done, it
> > should be a separate patch.
>
> What do you mean by a separate patch? Commit it before committing
> REINDEX CONCURRENTLY? If so, yes, sure. If you mean it can be fixed
> later, I don't really see how, since this is an unresolved problem...
>
Of course I meant that it would be necessary to validate the toast patch
first, it is a prerequisite for REINDEX CONCURRENTLY. Sorry for not being
that clear.


> > Also, as I am not a specialist in toast
> > indexes, any opinion about potential performance impact (if any) is
> welcome
> > if we remove reltoastidxid and use RelationGetIndexList instead.
>
> Tom doubted it will be really measurable, so did I... If anything I
> think it will be measurable during querying toast tables. So possibly we
> would have to retain reltoastidxid for querying...
>
> The minimal (not so nice) patch to make this correct probably is fairly
> easy.
>
> 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. 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.
-- 
Michael