On 3 October 2014 11:54, Heikki Linnakangas <hlinnakangas@vmware.com> wrote:
> Simon's approach would actually pass that test case just fine. It inserts
> the (promise) index tuple first, and heap tuple only after that. It will
> fail the test case with more than one unique index, however.
Please explain what you mean by "fail" here?
My understanding of what you're saying is that if
* we have a table with >1 unique index
* and we update the values of the uniquely index columns (e.g. PK update)
* on both of the uniquely indexed column sets
then we get occaisonal deadlocks, just as we would do using current
UPDATE/INSERT.
Is their a business use case that requires that? (Or exactly what you
meant, if that isn't it?)
My view is if we are going to base the whole design on this point,
then we need to have it very clearly accessible for all to understand.
-- Simon Riggs http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services