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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Performance of NOT IN and <> with PG 9.0.4
Дата
Msg-id BANLkTimbztAy9HrJX=bET1DZgmokNcCyzw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance of NOT IN and <> with PG 9.0.4  (Jasmin Dizdarevic <jasmin.dizdarevic@gmail.com>)
Список pgsql-sql
On Tue, May 24, 2011 at 5:10 PM, Jasmin Dizdarevic
<jasmin.dizdarevic@gmail.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


В списке pgsql-sql по дате отправления:

Предыдущее
От: Tarlika Elisabeth Schmitz
Дата:
Сообщение: Re: extracting location info from string
Следующее
От: Emi Lu
Дата:
Сообщение: Re: 500KB PDF files for postgresql8.3, which is the most efficient way?