Re: Allowing NOT IN to use ANTI joins - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Allowing NOT IN to use ANTI joins
Date
Msg-id 21551.1403650373@sss.pgh.pa.us
Whole thread Raw
In response to Re: Allowing NOT IN to use ANTI joins  (Simon Riggs <simon@2ndQuadrant.com>)
Responses Re: Allowing NOT IN to use ANTI joins  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 24 June 2014 23:44, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Simon Riggs <simon@2ndQuadrant.com> writes:
>>> Having said that, any join plan that relies upon a constraint will
>>> still be valid even if we drop a constraint while the plan executes
>>> because any new writes will not be visible to the executing join plan.

>> mumble ... EvalPlanQual ?

> As long as we are relaxing a constraint, we are OK if an earlier
> snapshot thinks its dealing with a tighter constraint whereas the new
> reality is a relaxed constraint.

I guess I should have been more explicit: EvalPlanQual processing could
see newer versions of tuples that might not satisfy the constraints the
plan was designed against.  Now, this is true only for the tuple that's
the target of the UPDATE/DELETE, so it's possible you could prove that
there's no problem --- but it would take careful analysis of the specific
semantics of the constraints in question.  I don't believe the argument
you've made here holds up.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Allowing join removals for more join types
Next
From: Tom Lane
Date:
Subject: Re: [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns