Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Andres Freund |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | 20130922203936.GA15659@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
|
Список | pgsql-hackers |
On 2013-09-22 12:54:57 -0700, Peter Geoghegan wrote: > On Sun, Sep 22, 2013 at 2:10 AM, Andres Freund <andres@2ndquadrant.com> wrote: > > I can't follow here. Why does e.g. the promise tuple approach bloat more > > than the subxact example? > > The protocol is roughly: > > 1) Insert index pointer containing an xid to be waiting upon instead of > > the target tid into all indexes > > 2) Insert heap tuple, we can be sure there's no conflict now > > 3) Go through the indexes and repoint the item to point to the tid of the > > heaptuple instead of the xid. > > > > There's zero heap or index bloat in the uncontended case. In the > > contended case it's just the promise tuples from 1) that are inserted > > before the conflict is detected. Those can be marked as dead when the > > conflict happened. > > It depends on your definition of the contended case. You're assuming > that insertion is the most probable outcome, when in fact much of the > time updating is just as likely or even more likely. Many promise > tuples may be inserted before actually seeing a conflict and deciding > to update/lock for update. I still fail to see how that's relevant. For every index there's two things that can happen: a) there's a conflicting tuple. In that case we can fail at that point/convert to an update. No Bloat. b) there's no conflicting tuple. In that case we will insert a promise tuple. If there's no conflict in further indexes (i.e. we INSERT), the promise will converted to a plain tuple. If there *is* a further conflict, you *still* need the new index tuple because by definition (the index changed) it cannot be an HOT update. So you convert it as well. No Bloat. > I think that bloat that is generally cleaned up synchronously is still > bloat I don't think it's particularly relevant because the above will just cause bloat in case of rollbacks and such which is nothin new, but: I fail to fee the point of such a position. > I think reviewer time would for now be much better spent discussing > the patch at a higher level (along the lines of my recent mail to > Stephen and Robert). Yes, I plan to reply to those, I just didn't have time to do so this weekend. There's other stuff than PG every now and then ;) Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: