Re: [PERFORM] Poor performance o

2006-03-22 Thread Jim C. Nasby
On Tue, Mar 21, 2006 at 05:04:16PM -0800, Craig A. James wrote: Tom Lane wrote: Craig A. James [EMAIL PROTECTED] 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,

[PERFORM] Poor performance o

2006-03-21 Thread Craig A. James
I'm reposting this -- I sent this out a month ago but never got a response, and hope someone can shed some light on this. Thanks, Craig -- This is a straightforward query that should be fairly quick, but takes about 30 minutes. It's a query across three tables, call

Re: [PERFORM] Poor performance o

2006-03-21 Thread Tom Lane
Craig A. James [EMAIL PROTECTED] 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

Re: [PERFORM] Poor performance o

2006-03-21 Thread Craig A. James
Tom Lane wrote: Craig A. James [EMAIL PROTECTED] 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

Re: [PERFORM] Poor performance o

2006-03-21 Thread Tom Lane
Craig A. James [EMAIL PROTECTED] writes: Tom Lane wrote: 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 = 2 work_mem = 32768