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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
