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

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