Re: Indices for select count(*)?
От
Greg Stark
Тема
Re: Indices for select count(*)?
Дата
Msg-id
87mzit86oa.fsf@stark.xeocode.com
Ответ на
Re: Indices for select count(*)? (Jim C. Nasby)
Список
Дерево обсуждения
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 по дате отправления