Re: Optimizer not using index on 120M row table - Mailing list pgsql-general

From Jim C. Nasby
Subject Re: Optimizer not using index on 120M row table
Date
Msg-id 20030407233509.Q31861@flake.decibel.org
Whole thread Raw
In response to Re: Optimizer not using index on 120M row table  (Neil Conway <neilc@samurai.com>)
Responses Re: Optimizer not using index on 120M row table  (Neil Conway <neilc@samurai.com>)
List pgsql-general
On Tue, Apr 08, 2003 at 12:29:00AM -0400, Neil Conway wrote:
> > I know in other RDBMS's it's very useful to
> > have index covering because it eliminates needing to load the base pages
> > into memory at all
>
> Storing visibility information in index entries (in addition to heap
> tuples) doesn't strike me as a good idea: for one thing, an
> UPDATE/DELETE would require touching both heap tuples and any index
> entries that point to them. It would also bloat the size of indexes.

True, though these could require touching the indexes anyway due to the
data changes (or at least I assume so, given how other RDBMS's work). It
might be a useful option to allow; in certain situations this could
provide fairly substantial gains, depending on how fat the index is
compared to the raw data rows.

It might also be worth allowing for a dirty read option if you don't
care about transactions that are in progress.
--
Jim C. Nasby (aka Decibel!)                    jim@nasby.net
Member: Triangle Fraternity, Sports Car Club of America
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"


pgsql-general by date:

Previous
From: "Jim C. Nasby"
Date:
Subject: Re: Optimizer not using index on 120M row table
Next
From: Tom Lane
Date:
Subject: Re: Optimizer not using index on 120M row table