Re: Why dose the planner select one bad scan plan.

From: tv(at)fuzzy(dot)cz
To: "pgsql-performance" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Why dose the planner select one bad scan plan.
Date: 2010-11-10 12:48:47
Message-ID: 507dc896562475ad862c40460520eda7.squirrel@sq.gransy.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-performance

> Okay, 225044.255ms VS 83813.808 ms, it obviously seems that the planner
> select one bad scan plan by default.

Actually no, the planner chose the cheapest plan (more precisely a plan
with the lowest computed cost). The first plan has a cost 600830.86 while
the second one has a cost 634901.28, so the first one is chosen.

To fix this, you'll have to tweak the cost variables, and maybe work_mem.
See this -
http://www.postgresql.org/docs/9.0/interactive/runtime-config-query.html#RUNTIME-CONFIG-QUERY-CONSTANTS
(but I'm not sure which of those influence the Bitmap Heap Scan /
HashAggregate plans).

So you'll have to modify these values until the hash aggregate plan is
cheaper. And you don't need to reboot the machine between EXPLAIN
executions. And even if you do EXPLAIN ANALYZE it's not necessary - there
are better ways to clear the filesystem cache.

BTW this is not a bug, so it's pointless to send it to 'bugs' mailinglist.

regards
Tomas

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruce Momjian 2010-11-10 13:26:41 Re: BUG #5735: pg_upgrade thinks that it did not start the old server
Previous Message Jin 2010-11-10 10:08:33 BUG #5745: geometry bug?

Browse pgsql-performance by date

  From Date Subject
Next Message Kevin Grittner 2010-11-10 15:15:50 Re: anti-join chosen even when slower than old plan
Previous Message Kevin Grittner 2010-11-10 12:38:43 Re: anti-join chosen even when slower than old plan