> 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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
