Tom Lane wrote:
> "Craig A. James" <cjames(at)modgraph-usa(dot)com> writes:
>> It looks to me like the problem is the use of nested loops when a hash
>> join should be used, but I'm no expert at query planning.
> Given the sizes of the tables involved, you'd likely have to boost up
> work_mem before the planner would consider a hash join. What nondefault
> configuration settings do you have, anyway?
shared_buffers = 20000
work_mem = 32768
effective_cache_size = 300000
This is on a 4GB machine. Is there a guideline for work_mem that's related to table size? Something like, "allow 2 MB per million rows"?
I'm also curious why the big difference between my "Query #1" and "Query #2". Even though it does a nested loop, #2's outer loop only returns one result from a very tiny table, so shouldn't it be virtually indistinguishable from #1?
In response to
pgsql-performance by date
|Next:||From: Vivek Khera||Date: 2006-03-22 02:22:52|
|Subject: Re: Best OS & Configuration for Dual Xeon w/4GB &|
|Previous:||From: Tom Lane||Date: 2006-03-21 23:33:15|
|Subject: Re: Poor performance o |
pgsql-hackers by date
|Next:||From: Andrew Dunstan||Date: 2006-03-22 02:04:00|
|Subject: Re: [GENERAL] A real currency type|
|Previous:||From: Jonah H. Harris||Date: 2006-03-22 00:14:05|
|Subject: Re: 8.2 planning features|