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 11956.1405458678@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  (David Rowley <dgrowleyml@gmail.com>)
List pgsql-hackers
Simon Riggs <simon@2ndQuadrant.com> writes:
> On 15 July 2014 12:58, David Rowley <dgrowleyml@gmail.com> wrote:
>> I found that the call to is_NOTANY_compatible_with_antijoin adds about 0.2%
>> and 2.3% to total planning time. Though the 2.3% was quite an extreme case,
>> and the 0.2% was the most simple case I could think of.

> Is there a way we can only run this extra test when we have reasonable
> idea that there is potential to save significant costs?

Well, all of this cost occurs only when we find a NOT IN clause in a place
where we could conceivably turn it into an antijoin.  I think it's
unquestionably a win to make that transformation if possible.  My concern
about it is mainly that the whole thing is a band-aid for naively written
queries, and it seems likely to me that naively written queries aren't
going to be amenable to making the proof we need.  But we can't tell that
for sure without doing exactly the work the patch does.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [COMMITTERS] pgsql: Reset master xmin when hot_standby_feedback disabled.
Next
From: Simon Riggs
Date:
Subject: Re: [COMMITTERS] pgsql: Reset master xmin when hot_standby_feedback disabled.