Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
От | Heikki Linnakangas |
---|---|
Тема | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Дата | |
Msg-id | 542562E9.9080804@vmware.com обсуждение исходный текст |
Ответ на | Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Re: INSERT ... ON CONFLICT {UPDATE | IGNORE} |
Список | pgsql-hackers |
On 09/26/2014 03:40 PM, Andres Freund wrote: > On 2014-09-26 15:32:35 +0300, Heikki Linnakangas wrote: >> On 09/26/2014 03:30 PM, Andres Freund wrote: >>> On 2014-09-26 15:24:21 +0300, Heikki Linnakangas wrote: >>>> I don't know what you mean by "in the head of AM", but IMO it would be far >>>> better if we can implement this outside the index AMs. Then it will work >>>> with any index AM. >>> >>> Also, it's the only chance to make this ever work across partitions. >> >> How so? Assuming there's no overlap in the partitions, you could lock the >> page in the index of the partition you're inserting to, just like you would >> insert the promise tuple to the right partition. > > Well, the 'no overlap' case is boring. Ok. > At least if you mean that each partition has disctinct value ranges > in the index? Right. > And the reason that the buffer locking approach in the overlapping case > is that you'd need to hold a large number of pages locked at the same > time. Right? Yeah, you would. To be honest, I didn't even think about the overlapping case, I just assumed that the overlapping case is the typical one and only thought about that. > But primarily I mean that bulk of the uniqueness checking logic has to > live outside the individual AMs. It doesn't sound enticing to reach from > inside one AM into another partitions index to do stuff. Yeah, that's a non-starter. Even with the index locking stuff, though, it wouldn't be the AM's responsibility to reach out to other partitions. - Heikki
В списке pgsql-hackers по дате отправления: