From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | David Rysdam <drysdam(at)ll(dot)mit(dot)edu> |
Cc: | bricklen <bricklen(at)gmail(dot)com>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: nested query vs left join: query planner very confused |
Date: | 2013-11-27 18:02:20 |
Message-ID: | 19462.1385575340@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
David Rysdam <drysdam(at)ll(dot)mit(dot)edu> writes:
> effective_cache_size - 12000MB
> shared_buffers - 1024MB
> random_page_cost - is commented out
> cpu_tuple_cost - commented out
> work_mem - commented out
> I assume you guys already know the default values for those last 3 on a
> 9.0.x server...
Default work_mem is only 1MB, so that probably explains why you're not
getting a hashed subplan here. Have them knock it up some, say on the
order of 10MB. (If none of your queries are any more complicated than
this one, you could go higher. But keep in mind that a backend can use
work_mem per sort/hash/materialize step, not per query --- so complex
queries can use many times work_mem. Multiply that by the number of
backends, and you can end up in swap hell pretty quickly with an over
optimistic value.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | David Rysdam | 2013-11-27 18:04:54 | Re: nested query vs left join: query planner very confused |
Previous Message | hubert depesz lubaczewski | 2013-11-27 16:54:43 | Re: help interpreting "explain analyze" output |