Re: Indices for select count(*)?

Поиск
Список
Период
Сортировка
Искать
От
Greg Stark
Тема
Re: Indices for select count(*)?
Дата
Msg-id
87mzit86oa.fsf@stark.xeocode.com
Ответ на
Список
Дерево обсуждения
Newbie Question: FAQ for database optimization? Alexander Scholz <alexander.scholz1@freenet.de>
Re: Newbie Question: FAQ for database optimization? "A. Kretschmer" <andreas.kretschmer@schollglas.com>
Indices for select count(*)? Alexander Scholz <alexander.scholz1@freenet.de>
Re: Indices for select count(*)? Peter Eisentraut <peter_e@gmx.net>
Re: Indices for select count(*)? Greg Stark <gsstark@mit.edu>
Re: Indices for select count(*)? "Jim C. Nasby" <jnasby@pervasive.com>
Re: Indices for select count(*)? Martijn van Oosterhout <kleptog@svana.org>
Re: Indices for select count(*)? "Jim C. Nasby" <jnasby@pervasive.com>
Re: Indices for select count(*)? Scott Marlowe <smarlowe@g2switchworks.com>
Re: Indices for select count(*)? Jaime Casanova <systemguards@gmail.com>
Re: Indices for select count(*)? Peter Eisentraut <peter_e@gmx.net>
Re: Indices for select count(*)? Tom Lane <tgl@sss.pgh.pa.us>
Re: Indices for select count(*)? Martijn van Oosterhout <kleptog@svana.org>
Re: Indices for select count(*)? Bruce Momjian <pgman@candle.pha.pa.us>
Re: Indices for select count(*)? Tom Lane <tgl@sss.pgh.pa.us>
Re: Indices for select count(*)? Tom Lane <tgl@sss.pgh.pa.us>
Re: Indices for select count(*)? Greg Stark <gsstark@mit.edu>
Re: Indices for select count(*)? Marcus Engene <mengpg@engene.se>
Re: Indices for select count(*)? Jaime Casanova <systemguards@gmail.com>
Re: Indices for select count(*)? Nicolas Barbier <nicolas.barbier@gmail.com>
Re: Newbie Question: FAQ for database optimization? David Fetter <david@fetter.org>

"Jim C. Nasby"  writes:

> I didn't think the method of adding the imperfect known_visible bit to
> the indexes had that much overhead, but it's been a while since those
> discussions took place. I do recall some issue being raised that will be
> very difficult to solve (though again I don't remember the details now).

I doubt very much any visibility information will ever make it into the
indexes. The cost to update it in all the indexes terrible, and when would
that update even happen?

The proposal that had the most going for it was to maintain a bit in the FSM
or something like it that was your "known visible" bit. That would speed up
index scans and vacuums too. It would largely solve the problem with vacuuming
large tables that have mostly untouched pages.

The reason Oracle gets away with this is because they use optimistic MVCC
where the new record replaces the old one entirely. They keep the old records
in a separate space entirely. You pay the costs elsewhere instead. In Oracle
every update requires updating the rollback segment too, and if you have a
very busy table each record can cause you a second (or even third or fourth)
read in the rollback segment. And you pay these costs on *all* scans.

-- 
greg
В списке pgsql-general по дате отправления
От: Jim C. Nasby
Дата:
От: Scott Marlowe
Дата:
FAQ