Re: Planner mis-estimation using nested loops followup

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/18/08, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
> On Tue, 18 Mar 2008 11:35:08 -0400
> "Chris Kratz" <chris(dot)kratz(at)vistashare(dot)com> wrote:
>
> > Nondefault settings of interest from postgresql.conf
> >
> >
> > shared_buffers = 1024MB # min 128kB or
> > max_connections*16kB work_mem = 256MB
> > # min 64kB maintenance_work_mem = 256MB # min 1MB
> > random_page_cost = 1.75 # same scale as above
> > effective_cache_size = 4096MB
> > default_statistics_target = 100 # range 1-1000
> >
> >
> > If nothing else, perhaps this will help somebody else who has run
> > into the same problem. If explain analyze of a query shows a large
> > mis-estimation of rows returned on a join (estimate=1, actual=2k)
> > causing the planner to choose nested loops instead of another join
> > type, you might try running the query with nested loops set to off
> > and see if that helps w/ performance.
>
>
> Did you try that? Did it work?
>
> Joshua D. Drake
>
>
> - --
> The PostgreSQL Company since 1997: http://www.commandprompt.com/
> PostgreSQL Community Conference: http://www.postgresqlconference.org/
> Donate to the PostgreSQL Project: http://www.postgresql.org/about/donate
> PostgreSQL political pundit | Mocker of Dolphins
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFH3+TlATb/zqfZUUQRAmXUAKCjwidfW0KXjzUM26I4yTx94/wSiQCfaqWU
> eI9i5yucBH718okW3w2UewQ=
> =BO3E
> -----END PGP SIGNATURE-----
>