Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}
Дата
Msg-id 20140926124047.GI1169@alap3.anarazel.de
обсуждение исходный текст
Ответ на Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Ответы Re: INSERT ... ON CONFLICT {UPDATE | IGNORE}  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
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. At least if you mean that each
partition has disctinct value ranges in the index?

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?

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.

Greetings,

Andres Freund

-- Andres Freund                       http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training &
Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Inefficient barriers on solaris with sun cc
Следующее
От: Oskari Saarenmaa
Дата:
Сообщение: Re: Inefficient barriers on solaris with sun cc