On 13.01.2011 02:01, Kevin Grittner wrote:
Anssi Kääriäinen<anssi.kaariai...@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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to