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@axege.com> 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
>
