> 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