Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0
От | Heikki Linnakangas |
---|---|
Тема | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 |
Дата | |
Msg-id | 55145549.6050704@iki.fi обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0 (Peter Geoghegan <pg@heroku.com>) |
Ответы |
Re: INSERT ... ON CONFLICT IGNORE (and UPDATE) 3.0
|
Список | pgsql-hackers |
On 03/26/2015 08:00 PM, Peter Geoghegan wrote: > On Wed, Mar 25, 2015 at 12:42 PM, Peter Geoghegan <pg@heroku.com> wrote: >> My next revision will have a more polished version of this scheme. I'm >> not going to immediately act on Robert's feedback elsewhere (although >> I'd like to), owing to time constraints - no reason to deny you the >> opportunity to review the entirely unrelated low-level speculative >> locking mechanism due to that. > > Attached revision, V3.1, implements this slightly different way of > figuring out if an insertion is speculative, as discussed. We reuse > t_ctid for speculatively inserted tuples. That's where the counter > goes. I think that this is a significant improvement, since there is > no longer any need to touch the proc array for any reason, without > there being any significant disadvantage that I'm aware of. I also > fixed some bitrot, and a bug with index costing (the details aren't > terribly interesting - tuple width wasn't being calculated correctly). Cool. Quickly looking at the patch though - does it actually work as it is? RelationPutHeapTuple will overwrite the ctid field when the tuple is put on the page, so I don't think the correct token will make it to disk as the patch stands. Also, there are a few places where we currently check if t_ctid equals the tuple's location, and try to follow t_ctid if it doesn't. I think those need to be taught that t_ctid can also be a token. - Heikki
В списке pgsql-hackers по дате отправления: