On Fri, Dec 18, 2009 at 7:32 PM, Tom Lane wrote:
> Robert Haas writes:
>> If at least one column in the subselect is strict, you can rewrite it
>> that way yourself, but the optimizer won't do it. I wish it did, but I
>> don't wish it badly enough to have written the code myself, and
>> apparentl
Robert Haas writes:
> If at least one column in the subselect is strict, you can rewrite it
> that way yourself, but the optimizer won't do it. I wish it did, but I
> don't wish it badly enough to have written the code myself, and
> apparently neither does anyone else.
I was thinking about this e
2009/12/18 Grzegorz Jaśkiewicz :
> 2009/12/18 Robert Haas :
>> 2009/12/18 Grzegorz Jaśkiewicz :
>>> On Fri, Dec 18, 2009 at 2:18 PM, Robert Haas wrote:
>>>
NOT IN is the only that really kills you as far as optimization is
concerned. IN can be transformed to a join. NOT IN forces a NOT
2009/12/18 Robert Haas :
> 2009/12/18 Grzegorz Jaśkiewicz :
>> On Fri, Dec 18, 2009 at 2:18 PM, Robert Haas wrote:
>>
>>> NOT IN is the only that really kills you as far as optimization is
>>> concerned. IN can be transformed to a join. NOT IN forces a NOT
>>> (subplan)-type plan, which bites -
2009/12/18 Grzegorz Jaśkiewicz :
> On Fri, Dec 18, 2009 at 2:18 PM, Robert Haas wrote:
>
>> NOT IN is the only that really kills you as far as optimization is
>> concerned. IN can be transformed to a join. NOT IN forces a NOT
>> (subplan)-type plan, which bites - hard.
>
> in a well designed dat
On Fri, Dec 18, 2009 at 2:18 PM, Robert Haas wrote:
> NOT IN is the only that really kills you as far as optimization is
> concerned. IN can be transformed to a join. NOT IN forces a NOT
> (subplan)-type plan, which bites - hard.
in a well designed database (read: not abusing NULLs) - it can b
On Thu, Dec 17, 2009 at 9:20 PM, Craig Ringer
wrote:
> On 17/12/2009 11:57 PM, Tom Lane wrote:
>>
>> Thomas Hamilton writes:
>>>
>>> But in our testing under the same optimization and conditions INNER JOIN
>>> is significantly outperforming IN.
>>
>> [ shrug... ] You haven't provided any details
On 17/12/2009 11:57 PM, Tom Lane wrote:
Thomas Hamilton writes:
But in our testing under the same optimization and conditions INNER JOIN is
significantly outperforming IN.
[ shrug... ] You haven't provided any details, so it's impossible to
offer any useful advice.
In other words: can we
On Thu, Dec 17, 2009 at 6:05 PM, Robert Haas wrote:
> On Thu, Dec 17, 2009 at 10:23 AM, Thomas Hamilton
> wrote:
>> Apparently the latest version of MySQL has solved this problem:
>> http://www.xaprb.com/blog/2006/06/28/why-large-in-clauses-are-problematic/
>>
>> But I am running PostgreSQL v8.3
On Thu, Dec 17, 2009 at 10:23 AM, Thomas Hamilton
wrote:
> Apparently the latest version of MySQL has solved this problem:
> http://www.xaprb.com/blog/2006/06/28/why-large-in-clauses-are-problematic/
>
> But I am running PostgreSQL v8.3 and am observing generally that SELECT ...
> WHERE ... IN (
Thomas Hamilton writes:
> But in our testing under the same optimization and conditions INNER JOIN is
> significantly outperforming IN.
[ shrug... ] You haven't provided any details, so it's impossible to
offer any useful advice.
regards, tom lane
--
Sent via pgsql-pe
Yes, I see the one note that running Analyze can improve the performance.
But in our testing under the same optimization and conditions INNER JOIN is
significantly outperforming IN.
- Original Message
From: Tom Lane t...@sss.pgh.pa.us
Thomas Hamilton writes:
> Apparently the latest
Thomas Hamilton writes:
> Apparently the latest version of MySQL has solved this problem:
> http://www.xaprb.com/blog/2006/06/28/why-large-in-clauses-are-problematic/
> But I am running PostgreSQL v8.3 and am observing generally that SELECT ...
> WHERE ... IN (a, b, c, ...) is much slower than S
13 matches
Mail list logo
