On Thu, Sep 16, 2010 at 10:13 AM, Franck Routier
franck.rout...@axege.com wrote:
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
Without knowing more about your queries and table structure, it is hard to
say if there is a better solution. But one thing you should probably
consider doing is just finding the queries where disabling nested loops is
verifiably effective and then just disabling nested loops on that connection
Franck Routier franck.rout...@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
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
Franck Routier franck.rout...@axege.com wrote:
So I wanted to better understand to what extend using a
sledgehammer will impact me :-)
Disabling it globally is likely to significantly hurt some queries.
Before resorting to that, you might decrease effective_cache_size,
increase
