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