Re: performance with query - Mailing list pgsql-performance

From Alberto Dalmaso
Subject Re: performance with query
Date
Msg-id 1245167677.5027.72.camel@dalmaso-opensuse.cl
Whole thread Raw
In response to Re: performance with query  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: performance with query  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: performance with query (OT)  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
List pgsql-performance
Il giorno mar, 16/06/2009 alle 11.31 -0400, Tom Lane ha scritto:
> Alberto Dalmaso <dalmaso@clesius.it> writes:
> > Il giorno mar, 16/06/2009 alle 15.58 +0100, Matthew Wakeling ha scritto:
> >>> enable_hashjoin = off
> >>> enable_nestloop = off
> >>> enable_seqscan = off
> >>> enable_sort = off
> >>
> >> Why are these switched off?
> >>
> > because of the need to pump up the performance of the complex query.
>
> That is *not* the way to improve performance of a query.  Turning off
> specific enable_ parameters can be helpful while investigating planner
> behavior, but it is never recommended as a production solution.  You
> have already found out why.
>
>             regards, tom lane
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?


pgsql-performance by date:

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