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

From Simon Riggs
Subject Re: Allowing NOT IN to use ANTI joins
Date
Msg-id CA+U5nMJOaY9wevO=W_a+nPbjy9NYMFEaikeRqyCKsmD=ezGDLQ@mail.gmail.com
Whole thread Raw
In response to Re: Allowing NOT IN to use ANTI joins  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 24 June 2014 23:52, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> 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.

OK, thanks for raising that. You're better at seeing these things than I.

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



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: API change advice: Passing plan invalidation info from the rewriter into the planner?
Next
From: Simon Riggs
Date:
Subject: Re: Allowing join removals for more join types