| From: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-general(at)postgresql(dot)org |
| Subject: | Re: Reliable and fast money transaction design |
| Date: | 2007-08-30 19:36:36 |
| Message-ID: | 20070830193636.GT7661@phlogiston.dyndns.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Thu, Aug 30, 2007 at 03:32:40PM -0400, Tom Lane wrote:
> difference is that SERIALIZABLE takes one snapshot at transaction start
> and works with that for the whole transaction, whereas READ COMMITTED
> takes a new snap for each statement.
Oh, I get it. This explains then why in principle READ COMMITTED
oughta be faster in the absence of conflicts: additional snapshot
checks are not needed? (Sorry to be obtuse. I think I had a
backward mental picture of how this worked: like SERIALIZABLE did
everything RC did, and then threw stuff away, or in any case did
additional work to ensure a nearly-mathematical serializability.)
A
--
Andrew Sullivan | ajs(at)crankycanuck(dot)ca
"The year's penultimate month" is not in truth a good way of saying
November.
--H.W. Fowler
| From | Date | Subject | |
|---|---|---|---|
| Next Message | André Volpato | 2007-08-30 19:45:04 | Metadata |
| Previous Message | Tom Lane | 2007-08-30 19:32:40 | Re: Reliable and fast money transaction design |