> > 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 ?
Yes, but that is done with a seq scan, but the index has to be read in
random order, since the index pages are not physically sorted on disk
from lowest to highest value. Of course you can spare the sort,
but overall ...
Imho spending effort on VACUUM is more fruitful, and has the potential to
allow much more concurrency than REINDEX, no ?
Andreas