Re: how to avoid deadlock on masive update with multiples delete - Mailing list pgsql-performance

From Andres Freund
Subject Re: how to avoid deadlock on masive update with multiples delete
Date
Msg-id 201210051833.55615.andres@2ndquadrant.com
Whole thread Raw
In response to Re: how to avoid deadlock on masive update with multiples delete  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
On Friday, October 05, 2012 05:46:05 PM Tom Lane wrote:
> Andres Freund <andres@2ndquadrant.com> writes:
> > On Friday, October 05, 2012 05:31:43 PM Tom Lane wrote:
> >> There's no guarantee that the planner won't re-sort the rows coming from
> >> the sub-select, unfortunately.
> >
> > More often than not you can prevent the planner from doing that by
> > putting a OFFSET 0 in the query. Not 100% but better than nothing.
>
> No, that will accomplish exactly nothing.  The ORDER BY is already an
> optimization fence.
Yea, sorry. I was thinking of related problem/solution.

> > We really need ORDER BY for DML.
>
> Meh.  That's outside the SQL standard (not only outside the letter of
> the standard, but foreign to its very conceptual model) and I don't
> think the problem really comes up that often.
Back when I mostly did consulting/development on client code it came up about
once a week. I might have  a warped view though because thats the kind of
thing you would ask a consultant about...

> Having said all that, are we sure this is even a deletion-order
> problem?  I was wondering about deadlocks from foreign key references,
> for instance.
Absolutely not sure, no.

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


pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: how to avoid deadlock on masive update with multiples delete
Next
From: "Anibal David Acosta"
Date:
Subject: Re: how to avoid deadlock on masive update with multiples delete