Re: SSI patch version 8

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: SSI patch version 8
Дата
Msg-id 4D2DEC9402000025000393DA@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: SSI patch version 8  (Anssi Kääriäinen <anssi.kaariainen@thl.fi>)
Ответы Re: SSI patch version 8  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
Anssi Kääriäinen<anssi.kaariainen@thl.fi> wrote:
> So, count(*) queries are more than twice as slow compared to the
> old serializable transaction isolation level.
I got this down from more than twice the run time to running 33%
longer through remembering the last relation for which a search for
a predicate lock held by the current transaction found a match at
the coarsest (relation) level.  It's a bit of a hack and 33% isn't
very impressive, even for a worst case (and this is one type of
worst case) -- especially given how often people use SELECT count(*)
FROM table_x as a performance test.  :-(
I can see a way to improve on this if there's a low-cost way to
determine from within the heapam.c:heapgettup_pagemode function
whether it's returning tuples for a table scan.  It seems likely
that this is somehow contained in the HeapScanDesc structure, but
I'm not seeing it.  Can anyone point me in the right direction, or
tell me that this avenue is a dead end?
Thanks,
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "David E. Wheeler"
Дата:
Сообщение: Re: arrays as pl/perl input arguments [PATCH]
Следующее
От: "David E. Wheeler"
Дата:
Сообщение: Re: Fixing GIN for empty/null/full-scan cases