Re: performance with query - Mailing list pgsql-performance

From Tom Lane
Subject Re: performance with query
Date
Msg-id 16299.1245168776@sss.pgh.pa.us
Whole thread Raw
In response to Re: performance with query  (Alberto Dalmaso <dalmaso@clesius.it>)
List pgsql-performance
Alberto Dalmaso <dalmaso@clesius.it> writes:
> Ok, but the problem is that my very long query performes quite well when
> it works with merge join but it cannot arrive to an end if it use other
> kind of joining.
> If i put all the parameter to on, as both of you tell me, in the
> explanation I'll see that the db use nasted loop.
> If i put to off nasted loop, it will use hash join.
> How can I write the query so that the analyzer will use mergejoin (that
> is the only option that permit the query to give me the waited answare)
> without changing the settings every time on the connection?

You have the wrong mindset completely.  Instead of thinking "how can I
force the planner to do it my way", you need to be thinking "why is the
planner guessing wrong about which is the best way to do it?  And how
can I improve its guess?"

There's not really enough information in what you've posted so far to
let people help you with that question, but one thing that strikes me
from the EXPLAIN is that you have a remarkably large number of joins.
Perhaps increasing from_collapse_limit and/or join_collapse_limit
(to more than the number of tables in the query) would help.

            regards, tom lane

pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: performance with query
Next
From: Alberto Dalmaso
Date:
Subject: Re: performance with query