Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
От | Peter Geoghegan |
---|---|
Тема | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE |
Дата | |
Msg-id | CAM3SWZQVUpwUocUpRBbFiss5QzHgYN81HNWArn164BMTJ+dDuA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE (Andres Freund <andres@2ndquadrant.com>) |
Список | pgsql-hackers |
On Sun, Sep 22, 2013 at 1:39 PM, Andres Freund <andres@2ndquadrant.com> wrote: > 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. Well, yes - if the conflict is in the first unique index you look at. > b) there's no conflicting tuple. In that case we will insert a promise > tuple. Yeah, if there is no conflict relating to any of the tuples, the cost is limited to updating the promise tuples in-place. Not exactly a trivial additional cost even then though, because you have to exclusive lock and WAL-log twice per index tuple. > If there's no conflict in further indexes (i.e. we INSERT), the > promise will converted to a plain tuple. Sure. > 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. By definition? What do you mean? This isn't MySQL's REPLACE. This feature is almost certainly going to tacitly require the user to write the upsert SQL with a particular unique index in mind (to figure that out for ourselves, we'd need to somehow ask/infer, which is ugly/very hard to impossible). The UPDATE, as typically written, probably *won't* actually update any of the other, incidentally unique-constrained/value locked columns that we have to check in case that's what the user really meant, and very probably not the "interesting" column appearing in the UPDATE qual itself, so it probably *will* be a HOT update. > So you convert it as > well. No Bloat. Even if this is a practical possibility, which I doubt, the book keeping sounds very messy and invasive indeed. > Yes, I plan to reply to those, I just didn't have time to do so this > weekend. Great, thanks. I cannot strongly emphasize enough how I think that's the way to frame all of this. So much so that I almost managed to resist answering the above points. :-) > There's other stuff than PG every now and then ;) Hope you enjoyed the hike. -- Peter Geoghegan
В списке pgsql-hackers по дате отправления: