Lists: | pgsql-hackers |
---|
From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Snapshot Reuse |
Date: | 2008-02-27 22:45:38 |
Message-ID: | 1204152338.4252.642.camel@ebony.site |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
In Read Committed transactions we take snapshots much more frequently
than transactions begin and commit. It would be help scalability if we
didn't need to re-take a snapshot. That's only helpful if the chances of
seeing the snapshot is relatively high.
Now that we have virtual transactions we may more frequently find
ourselves taking identical snapshots.
If we had a counter that incremented each time the main snapshot altered
in a meaningful way we could set that atomically. We could then read
this when we take a snapshot to see if it matches our existing snapshot;
if so then drop the lock quickly and continue with what we already have.
I can see some downsides to this as well as potential benefits:
* we ping the counter across CPUs - yes, we will, but that's probably
better than pinging the whole procarray
* this relies upon the rate of change of snapshots - need to do the math
to see how often this might apply
Not sure yet myself, but it seems worth recording in case it spurs an
idea from someone else.
--
Simon Riggs
2ndQuadrant http://www.2ndQuadrant.com
From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Snapshot Reuse |
Date: | 2008-03-03 19:05:50 |
Message-ID: | 200803031905.m23J5oL25303@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Lists: | pgsql-hackers |
I certainly would be interested to see if it improves performance.
---------------------------------------------------------------------------
Simon Riggs wrote:
> In Read Committed transactions we take snapshots much more frequently
> than transactions begin and commit. It would be help scalability if we
> didn't need to re-take a snapshot. That's only helpful if the chances of
> seeing the snapshot is relatively high.
>
> Now that we have virtual transactions we may more frequently find
> ourselves taking identical snapshots.
>
> If we had a counter that incremented each time the main snapshot altered
> in a meaningful way we could set that atomically. We could then read
> this when we take a snapshot to see if it matches our existing snapshot;
> if so then drop the lock quickly and continue with what we already have.
>
> I can see some downsides to this as well as potential benefits:
>
> * we ping the counter across CPUs - yes, we will, but that's probably
> better than pinging the whole procarray
>
> * this relies upon the rate of change of snapshots - need to do the math
> to see how often this might apply
>
> Not sure yet myself, but it seems worth recording in case it spurs an
> idea from someone else.
>
> --
> Simon Riggs
> 2ndQuadrant http://www.2ndQuadrant.com
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 2: Don't 'kill -9' the postmaster
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://postgres.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +