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>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "PostgreSQL-development" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: SSI performance
Date: 2011-02-04 23:25:25
Message-ID: 4D4C3685020000250003A425@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I wrote:

> repeatable read
> [best] Time: 51.150 ms

> serializable
> [best] Time: 52.089 ms

It occurred to me that taking the best time from each was likely to
give a reasonable approximation of the actual overhead of SSI in
this situation. That came out to about 1.8% in this (small) set of
tests, which is right where earlier benchmarks of a heavy read load
against fully-cached data put the SSI predicate locking overhead.
That previous benchmarking involved letting things run overnight for
several days in a row to accumulate hundreds of runs of decent
length. While today's little test doesn't prove much, because of
its size, the fact that it matches the numbers from the earlier,
more rigorous tests suggests that we're probably still in the same
ballpark.

If you get into a load where there's actual disk access, I suspect
that this overhead will be very hard to spot; the transaction
rollback rate is going to become the dominant performance issue.

-Kevin

In response to

Browse pgsql-hackers by date

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