From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
Cc: | David Rowley <dgrowleyml(at)gmail(dot)com>, Jeevan Chalke <jeevan(dot)chalke(at)enterprisedb(dot)com>, Marti Raudsepp <marti(at)juffo(dot)org>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Allowing NOT IN to use ANTI joins |
Date: | 2014-07-15 21:11:18 |
Message-ID: | 11956.1405458678@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Simon Riggs <simon(at)2ndQuadrant(dot)com> writes:
> On 15 July 2014 12:58, David Rowley <dgrowleyml(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Simon Riggs | 2014-07-15 21:19:18 | Re: [COMMITTERS] pgsql: Reset master xmin when hot_standby_feedback disabled. |
Previous Message | Tom Lane | 2014-07-15 21:01:03 | Re: [COMMITTERS] pgsql: Reset master xmin when hot_standby_feedback disabled. |