Re: Improving backend launch time by preloading relcache

From: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
To: Zeugswetter Andreas SB SD <ZeugswetterA(at)spardat(dot)at>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Improving backend launch time by preloading relcache
Date: 2002-01-31 02:07:56
Message-ID: 3C58A6FC.469CB6A@tpf.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Clift 2002-01-31 02:19:24 Re: A simpler way to configure the source code?
Previous Message Peter Eisentraut 2002-01-31 02:03:05 Re: Per-database and per-user GUC settings