Thanks Kevin and Samuel for your input. The point is we already made a lot of tweaking to try to tune postgresql to behave correctly. I work with Damien, and here is a post he did in july to explain the kind of problems we have http://comments.gmane.org/gmane.comp.db.postgresql.performance/25745 The end of the thread was Robert Hass concluding that "Disabling nestloops altogether, even for one particular query, is often going to be a sledgehammer where you need a scalpel. But then again, a sledgehammer is better than no hammer." So I wanted to better understand to what extend using a sledgehammer will impact me :-) Franck Le jeudi 16 septembre 2010 à 08:49 -0500, Kevin Grittner a écrit : > Franck Routier <franck.routier@xxxxxxxxx> wrote: > > > I come into cases where the planner under-estimates the number of > > rows in some relations, chooses to go for nested loops, and takes > > forever to complete the request. > > People can provide more targeted assistance if you pick one of the > offenders and provide enough information for a thorough analysis. > It's at least somewhat likely that some tweaks to your configuration > or maintenance procedures could help all the queries, but starting > with just one is likely to highlight what those changes might be. > > For ideas on what information to include, see this page: > > http://wiki.postgresql.org/wiki/SlowQueryQuestions > > -Kevin > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
