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