Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Bruce Momjian |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | 20130926031912.GA31933@momjian.us обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
|
Список | 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@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
В списке pgsql-hackers по дате отправления: