From: | Dan Ports <drkp(at)csail(dot)mit(dot)edu> |
---|---|
To: | Greg Sabino Mullane <greg(at)endpoint(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Overhead cost of Serializable Snapshot Isolation |
Date: | 2011-10-10 19:45:50 |
Message-ID: | 20111010194550.GD7608@csail.mit.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Oct 10, 2011 at 02:25:59PM -0400, Greg Sabino Mullane wrote:
> I agree it is better versus SELECT FOR, but what about repeatable read versus
> the new serializable? How much overhead is there in the 'monitoring of
> read/write dependencies'? This is my only concern at the moment. Are we
> talking insignificant overhead? Minor? Is it measurable? Hard to say without
> knowing the number of txns, number of locks, etc.?
I'd expect that in most cases the main cost is not going to be overhead
from the lock manager but rather the cost of having transactions
aborted due to conflicts. (But the rollback rate is extremely
workload-dependent.)
We've seen CPU overhead from the lock manager to be a few percent on a
CPU-bound workload (in-memory pgbench). Also, if you're using a system
with many cores and a similar workload, SerializableXactHashLock might
become a scalability bottleneck.
Dan
--
Dan R. K. Ports MIT CSAIL http://drkp.net/
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2011-10-10 19:59:04 | Re: Overhead cost of Serializable Snapshot Isolation |
Previous Message | Heikki Linnakangas | 2011-10-10 19:30:35 | Re: Overhead cost of Serializable Snapshot Isolation |