Re: SSI performance

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Dan Ports" <drkp(at)csail(dot)mit(dot)edu>, "Heikki Linnakangas" <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI performance
Date: 2011-02-04 23:11:28
Message-ID: 4D4C3340020000250003A41F@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:

>> If this works, it would be a very minor change, which might
>> eliminate a lot of that overhead for many common cases.

With that change in place, I loaded actual data from one county for
our most heavily searched table and searched it on the most heavily
searched index. I returned actual data rather than a count, from
3654 rows. On a less trivial and more common query like this, the
overhead of SSI tends to be lost in the noise:

select "nameL", "nameF", "nameM", "suffix",
"countyNo", "caseNo", "sex"
from "Party"
where "searchName" like 'WILLIAMS,%'
order by "countyNo", "caseNo";

repeatable read
Time: 51.150 ms
Time: 54.809 ms
Time: 53.495 ms
Time: 51.458 ms
Time: 82.656 ms

serializable
Time: 54.105 ms
Time: 52.765 ms
Time: 52.852 ms
Time: 69.449 ms
Time: 52.089 ms

Unfortunately for those who rely on count(*), it is about the worst
case possible for highlighting SSI predicate locking overhead.

-Kevin

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2011-02-04 23:17:12 Re: [HACKERS] Slow count(*) again...
Previous Message Josh Berkus 2011-02-04 23:05:23 Re: Linux filesystem performance and checkpoint sorting