Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE

Поиск
Список
Период
Сортировка
От Heikki Linnakangas
Тема Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE
Дата
Msg-id 52D799BF.8030502@vmware.com
обсуждение исходный текст
Ответ на Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Peter Geoghegan <pg@heroku.com>)
Ответы Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Peter Geoghegan <pg@heroku.com>)
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Robert Haas <robertmhaas@gmail.com>)
Re: INSERT...ON DUPLICATE KEY LOCK FOR UPDATE  (Peter Geoghegan <pg@heroku.com>)
Список pgsql-hackers
On 01/16/2014 03:25 AM, Peter Geoghegan wrote:
> I think you should consider breaking off the relcache parts of my
> patch and committing them, because they're independently useful. If we
> are going to have a lot of conflicts that need to be handled by a
> heap_delete(), there is no point in inserting non-unique index tuples
> for what is not yet conclusively a proper (non-promise) tuple. Those
> should always come last. And even without upsert, strictly inserting
> into unique indexes first seems like a useful thing relative to the
> cost. Unique violations are the cause of many aborted transactions,
> and there is no need to ever bloat non-unique indexes of the same slot
> when that happens.

Makes sense. Can you extract that into a separate patch, please?

I was wondering if that might cause deadlocks if an existing index is 
changed from unique to non-unique, or vice versa, as the ordering would 
change. But we don't have a DDL command to change that, so the question 
is moot.

- Heikki



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

Предыдущее
От: knizhnik
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Следующее
От: Rushabh Lathia
Дата:
Сообщение: Re: Display oprcode and its volatility in \do+