From: | Peter Geoghegan <pg(at)heroku(dot)com> |
---|---|
To: | Heikki Linnakangas <hlinnakangas(at)vmware(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Date: | 2014-01-11 11:13:02 |
Message-ID: | CAM3SWZQ+Z5t=A9skY6fQGL_Bk_ES_5YbaYnh7KDurs90-sCrAw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 11, 2014 at 2:39 AM, Peter Geoghegan <pg(at)heroku(dot)com> wrote:
> So I re-ran the same old benchmark, where we're almost exclusively
> updating. Results for your latest revision were very similar to my
> patch:
>
> http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/exclusion-no-deadlock/
To put that in context, here is a previously unpublished repeat of the
same benchmark on the slightly improved second most recently submitted
revision of mine, v6:
http://postgres-benchmarks.s3-website-us-east-1.amazonaws.com/upsert-cmp-3/
(recall that I improved things a bit by remember row-locking
conflicts, not just conflicts when we try value locking - that made a
small additional difference, reflected here but not in /upsert-cmp-2/
).
The numbers for each patch are virtually identical. I guess I could
improve my patch by not always getting a heavyweight lock on the first
insert attempt, based on the general observation that we have
previously always updated. My concern would be that that would happen
at the expense of the other case.
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2014-01-11 12:25:12 | Re: Simple improvements to freespace allocation |
Previous Message | Peter Geoghegan | 2014-01-11 10:39:28 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |