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
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
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
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
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/
-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
