Re: Improving backend launch time by preloading relcache

Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp> writes:
> I thought of another idea while reading the thread [HACKERS]
> sequence indexes. Currently REINDEX recreates indexes from
> the heap relations because the indexes may be corrupted.
> However we can recreate indexes from existent ones if
> they are sane. It would be a lot faster than the current
> way for large tables.

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. 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. This'd
require hacking things deep in the guts of the btree index method,
not at the level of the present REINDEX code. And AFAICS it doesn't
translate at all to the other index types.

Not sure it's worth the trouble. I'd rather see us expend the same
effort on shrinking indexes on-the-fly in VACUUM.

regards, tom lane