On 13.01.2011 02:01, Kevin Grittner wrote:
> 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?
Pardon my ignorance, but where exactly is the extra overhead coming
from? Searching for a predicate lock?
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com
