Re: Allowing NOT IN to use ANTI joins

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Allowing NOT IN to use ANTI joins
Дата
Msg-id 21551.1403650373@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Allowing NOT IN to use ANTI joins  (Simon Riggs <simon@2ndQuadrant.com>)
Ответы Re: Allowing NOT IN to use ANTI joins
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Allowing join removals for more join types
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [BUGS] BUG #10728: json_to_recordset with nested json objects NULLs columns