Re: Is disableing nested_loops a bad idea ?

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
before running the query and then reset after the query completes. That
way, you won't impact queries that legitimately use nested loops. Someone
with more experience than I have in tuning the general postgres config may
be able to offer a better solution for getting the query planner to make
better decisions with the global config, but they'll surely need to know a
lot more about your queries in order to do so.

On Thu, Sep 16, 2010 at 1:23 AM, Franck Routier <franck(dot)routier(at)axege(dot)com>wrote:

> Hi,
>
> I am confronted with a use case where my database mainly does big
> aggregate select (ROLAP), a bunch of batch jobs, and quite few OLTP.
>
> 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. (Notice as the side note that Oracle (10g or 11g)
> is not any better on this workload and will sometime go crazy and choose
> a plan that takes hours...)
>
> I've played with statistics, vacuum and so on, but at the end the
> planner is not accurate enough when evaluating the number of rows in
> some complex queries.
>
> Disableing nested loops most of the time solves the performance issues
> in my tests... generally going from 30 sec. down to 1 sec.
>
> So my question is : would it be a very bad idea to disable nested loops
> in production ?
> The way I see it is that it could be a little bit less optimal to use
> merge join or hash join when joining on a few rows, but this is peanuts
> compared to how bad it is to use nested loops when the number of rows
> happens to be much higher than what the planner thinks.
>
> Is this stupid, ie are there cases when merge join or hash join are much
> slower than nested loops on a few rows ?
>
> Thanks in advance,
>
> Franck
>
>
>
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>