Re: Improving backend launch time by preloading relcache - Mailing list pgsql-hackers

From Hiroshi Inoue
Subject Re: Improving backend launch time by preloading relcache
Date
Msg-id 3C58A6FC.469CB6A@tpf.co.jp
Whole thread Raw
In response to Re: Improving backend launch time by preloading relcache  ("Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at>)
Responses Re: Improving backend launch time by preloading relcache  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Zeugswetter Andreas SB SD wrote:
> 
> > > 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 ...

Reading a index file is not faster than reading the heap file ?
Does sorting finish in a moment ?
If so we have to use sequential scan much more often.

Anyway there seems no point on changing REINDEX.
The only thing I have to do is to remove the needless
check in tcop/utility.c as soon as 7.2 is released.

regards,
Hiroshi Inoue


pgsql-hackers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: A simpler way to configure the source code?
Next
From: Peter Eisentraut
Date:
Subject: Re: Per-database and per-user GUC settings