Re: [PERFORM] Planner mis-estimation using nested loops followup

2008-03-18 Thread KC ESL
At 00:24 08/03/19, Matthew wrote: On Tue, 18 Mar 2008, Chris Kratz wrote: In moderately complex to very complex ad hoc queries in our system, we were consistently having the system massively underestimate the number of rows coming out of join at a low level making these queries very slow and i

Re: [PERFORM] Planner mis-estimation using nested loops followup

2008-03-18 Thread Stephen Denne
Scott Marlowe wrote > On Tue, Mar 18, 2008 at 9:58 AM, Chris Kratz > <[EMAIL PROTECTED]> wrote: > > Y, turning nested loops off in specific cases has increased > performance > > greatly. It didn't fix the planner mis-estimation, just > the plan it chose. > > It's certainly not a panacea, but it

Re: [PERFORM] Planner mis-estimation using nested loops followup

2008-03-18 Thread Scott Marlowe
On Tue, Mar 18, 2008 at 9:58 AM, Chris Kratz <[EMAIL PROTECTED]> wrote: > Y, turning nested loops off in specific cases has increased performance > greatly. It didn't fix the planner mis-estimation, just the plan it chose. > It's certainly not a panacea, but it's something we now try early on when

Re: [PERFORM] Planner mis-estimation using nested loops followup

2008-03-18 Thread Matthew
On Tue, 18 Mar 2008, Chris Kratz wrote: In moderately complex to very complex ad hoc queries in our system, we were consistently having the system massively underestimate the number of rows coming out of join at a low level making these queries very slow and inefficient. I have long thought t

Re: [PERFORM] Planner mis-estimation using nested loops followup

2008-03-18 Thread Chris Kratz
Y, turning nested loops off in specific cases has increased performance greatly. It didn't fix the planner mis-estimation, just the plan it chose. It's certainly not a panacea, but it's something we now try early on when trying to speed up a query that matches these characteristics. -Chris On 3/

Re: [PERFORM] Planner mis-estimation using nested loops followup

2008-03-18 Thread Joshua D. Drake
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, 18 Mar 2008 11:35:08 -0400 "Chris Kratz" <[EMAIL PROTECTED]> wrote: > Nondefault settings of interest from postgresql.conf > > > shared_buffers = 1024MB # min 128kB or > max_connections*16kB work_mem = 256MB > # min 64kB main

[PERFORM] Planner mis-estimation using nested loops followup

2008-03-18 Thread Chris Kratz
A number of weeks ago, I had posted a request for help regarding join estimates in pg 8.2.6. In moderately complex to very complex ad hoc queries in our system, we were consistently having the system massively underestimate the number of rows coming out of join at a low level making these queries