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 NULLs inside the
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:
I agree, but
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
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
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)---
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.
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
