Re: performance with query

Поиск
Список
Период
Сортировка
От Alberto Dalmaso
Тема Re: performance with query
Дата
Msg-id 1245167677.5027.72.camel@dalmaso-opensuse.cl
обсуждение исходный текст
Ответ на Re: performance with query  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: performance with query
Re: performance with query (OT)
Список 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 по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: performance with query
Следующее
От: "Kevin Grittner"
Дата:
Сообщение: Re: performance with query