Re: Performance of NOT IN and <> with PG 9.0.4

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jasmin Dizdarevic <jasmin(dot)dizdarevic(at)gmail(dot)com>
Cc: pgsql-sql(at)postgresql(dot)org
Subject: Re: Performance of NOT IN and <> with PG 9.0.4
Date: 2011-05-25 19:49:31
Message-ID: BANLkTimbztAy9HrJX=bET1DZgmokNcCyzw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-sql

On Tue, May 24, 2011 at 5:10 PM, Jasmin Dizdarevic
<jasmin(dot)dizdarevic(at)gmail(dot)com> wrote:
> That's strange...
> If I comment out these rows
> --sum(coalesce(e.num_wert,0)),
> --sum(coalesce(d.num_wert,0))
> in the given statement, it works fine with enable_material = 'on'.
> I didn't change any join.

That's not that strange. The planner thinks that the cost of the plan
you're getting with enable_material=on is 729721.34, and the cost of
the plan you're getting with enable_material=off is 727904.40, or
approximately an 0.2% difference. Any little change you make to
anything in the system, or just random changes in your statistics,
could cause the plans to bounce back and forth between those two. The
real question is why the planner thinks those two cost about the same,
when in reality one of them is way faster than the other. You might
want to look through the EXPLAIN ANALYZE output and try to figure out
which part of the plan is being mis-estimated.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-sql by date

  From Date Subject
Next Message Tarlika Elisabeth Schmitz 2011-05-25 21:13:42 Re: extracting location info from string
Previous Message Tarlika Elisabeth Schmitz 2011-05-25 18:14:04 Re: extracting location info from string