Re: Optimizer not using index on 120M row table
От | Jim C. Nasby |
---|---|
Тема | Re: Optimizer not using index on 120M row table |
Дата | |
Msg-id | 20030407233509.Q31861@flake.decibel.org обсуждение исходный текст |
Ответ на | Re: Optimizer not using index on 120M row table (Neil Conway <neilc@samurai.com>) |
Ответы |
Re: Optimizer not using index on 120M row table
|
Список | 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 по дате отправления: