Re: Improving backend launch time by preloading relcache

From: "Zeugswetter Andreas SB SD" <ZeugswetterA(at)spardat(dot)at>
To: "Hiroshi Inoue" <Inoue(at)tpf(dot)co(dot)jp>, "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Improving backend launch time by preloading relcache
Date: 2002-01-30 10:21:42
Message-ID: 46C15C39FEB2C44BA555E356FBCD6FA41EB4CA@m0114.s-mxs.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> > 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Zeugswetter Andreas SB SD 2002-01-30 10:25:31 Re: Syscaches should store negative entries, too
Previous Message Luis Amigo 2002-01-30 08:52:01 Re: inline is not ANSI C