Tom Lane wrote:
>
> Hmm ... you are thinking about the case where REINDEX is being used
> not to recover from corruption, but just to shrink indexes that have
> accumulated too much free space.
Yes.
> Okay, that's a reasonable case to
> try to optimize, though I'd like to think the problem will go away
> in a release or two when we implement VACUUM-time index shrinking.
>
> However, I'm not sure about the "lot faster" part. The only win
> I can see is that when rebuilding a btree index, you could skip
> the sort step by reading the old index in index order.
Don't we have to scan the (possibly larger) heap table ?
regards,
Hiroshi Inoue