On Fri, 18 Jun 2004, [iso-8859-1] SZUCS Gábor wrote:
> Dear Gurus,
>
> - Original Message -
> From: "Stephan Szabo" <[EMAIL PROTECTED]>
> Sent: Thursday, June 10, 2004 7:14 PM
>
>
> >
> > On Thu, 10 Jun 2004, Stephan Szabo wrote:
> >
> > >
> > > On Thu, 10 Jun 2004, Jean-Luc Lachance wrote
=?iso-8859-1?Q?SZUCS_G=E1bor?= <[EMAIL PROTECTED]> writes:
>> It's NULLs inside the subselect that are the issue.
>
> select 1 in (select a from foo)
> select exists ( select 1 from foo where a=1)
> Just a dumb try :)
> SELECT (exists(select 1 from foo where a isnull) AND NULL)
>OR exi
Dear Gurus,
- Original Message -
From: "Stephan Szabo" <[EMAIL PROTECTED]>
Sent: Thursday, June 10, 2004 7:14 PM
>
> On Thu, 10 Jun 2004, Stephan Szabo wrote:
>
> >
> > On Thu, 10 Jun 2004, Jean-Luc Lachance wrote:
> >
> > > I agree, but it should be a simple rewrite. No?
> >
> > It's N
On Thu, 10 Jun 2004, Stephan Szabo wrote:
>
> On Thu, 10 Jun 2004, Jean-Luc Lachance wrote:
>
> > I agree, but it should be a simple rewrite. No?
>
> It's NULLs inside the subselect that are the issue.
>
> select 1 in (select a from foo)
> select exists ( select 1 from foo where a=1)
>
> If foo.a
On Thu, 10 Jun 2004, Jean-Luc Lachance wrote:
> I agree, but it should be a simple rewrite. No?
It's NULLs inside the subselect that are the issue.
select 1 in (select a from foo)
select exists ( select 1 from foo where a=1)
If foo.a contains a row with NULL but no rows containing a 1, the abo
I agree, but it should be a simple rewrite. No?
x IS NULL/IS NOT NULL AND/OR NOT EXISTS
Tom Lane wrote:
Jean-Luc Lachance <[EMAIL PROTECTED]> writes:
If the two statments are functionally equivalent, why can't PG rewrite
the "NOT IN" version into the more efficient "NOT EXISTS"?
They're not equiv
Jean-Luc Lachance <[EMAIL PROTECTED]> writes:
> If the two statments are functionally equivalent, why can't PG rewrite
> the "NOT IN" version into the more efficient "NOT EXISTS"?
They're not equivalent. In particular, the behavior in the presence of
NULLs is quite different.
The real question is:
If the two statments are functionally equivalent, why can't PG rewrite
the "NOT IN" version into the more efficient "NOT EXISTS"?
Frank van Vugt wrote:
L.S.
Could anybody explain why the planner is doing what it is doing?
What could I do to make it easier to choose a better
Wow,
The effectiveness of the pgsql mailinglists never ceases to amaze me.
Default sort mem it was, I guess I'd simply been to cautious with this
per-client setting.
Stephan & Tom : thanks!
--
Best,
Frank.
---(end of broadcast)---
TI
Frank van Vugt <[EMAIL PROTECTED]> writes:
> What could I do to make it easier to choose a better plan?
Increase sort_mem. You want it to pick a "hashed subplan", but
it's not doing so because 64000 rows won't fit in the default
sort_mem.
regards, tom lane
--
On Thu, 10 Jun 2004, Frank van Vugt wrote:
> Could anybody explain why the planner is doing what it is doing?
>
> What could I do to make it easier to choose a better plan?
You might try raising sort_mem to see if it chooses a better plan. I
think it may be guessing that the hash won't fit and
11 matches
Mail list logo
