Re: SSI patch version 8 - Mailing list pgsql-hackers

From Kevin Grittner
Subject Re: SSI patch version 8
Date
Msg-id 4D2DEC9402000025000393DA@gw.wicourts.gov
Whole thread Raw
In response to Re: SSI patch version 8  (Anssi Kääriäinen <anssi.kaariainen@thl.fi>)
Responses Re: SSI patch version 8  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
List 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 by date:

Previous
From: "David E. Wheeler"
Date:
Subject: Re: arrays as pl/perl input arguments [PATCH]
Next
From: "David E. Wheeler"
Date:
Subject: Re: Fixing GIN for empty/null/full-scan cases