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 <[EMAIL PROTECTED]> wrote: > > -----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 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----- >
