| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)heroku(dot)com> |
| Cc: | Andres Freund <andres(at)2ndquadrant(dot)com>, Greg Stark <stark(at)mit(dot)edu>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
| Date: | 2013-09-26 03:19:12 |
| Message-ID: | 20130926031912.GA31933@momjian.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sat, Sep 21, 2013 at 05:07:11PM -0700, Peter Geoghegan wrote:
> In the average/uncontended case, the subxact example bloats less than
> all alternatives to my design proposed to date (including the "unborn
> heap tuple" idea Robert mentioned in passing to me in person the other
> day, which I think is somewhat similar to a suggestion of Heikki's
> [1]). The average case is very important, because in general
> contention usually doesn't happen.
This thread had a lot of discussion about bloating. I wonder, does the
code check to see if there is a matching row _before_ adding any data?
Our test-and-set code first checks to see if the lock is free, then if
it it is, it locks the bus and does a test-and-set. Couldn't we easily
check the indexes for matches before doing any locking? It seems that
would avoid bloat in most cases, and allow for a simpler implementation.
--
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ It's impossible for everything to be true. +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2013-09-26 03:48:11 | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
| Previous Message | Noah Misch | 2013-09-26 03:14:13 | Re: pgbench progress report improvements - split 2 |