Re: SSI patch version 8

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: Anssi Kääriäinen <anssi(dot)kaariainen(at)thl(dot)fi>
Cc: "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>, "john(dot)okite(at)gmail(dot)org" <john(dot)okite(at)gmail(dot)org>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI patch version 8
Date: 2011-01-13 00:01:56
Message-ID: 4D2DEC9402000025000393DA@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Anssi Kääriäinen<anssi(dot)kaariainen(at)thl(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David E. Wheeler 2011-01-13 00:08:22 Re: Fixing GIN for empty/null/full-scan cases
Previous Message David E. Wheeler 2011-01-12 23:37:34 Re: arrays as pl/perl input arguments [PATCH]