Re: Measuring the Query Optimizer Effect: Turning off the QO?

Поиск
Список
Период
Сортировка
От Andrew Gierth
Тема Re: Measuring the Query Optimizer Effect: Turning off the QO?
Дата
Msg-id 87muho5x24.fsf@news-spur.riddles.org.uk
обсуждение исходный текст
Ответ на Re: Measuring the Query Optimizer Effect: Turning off the QO?  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Measuring the Query Optimizer Effect: Turning off the QO?  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes:

 Tom> Two I'd particularly draw your attention to are
 Tom> join_collapse_limit and from_collapse_limit --- if you set both to
 Tom> 1, that'll effectively disable searching for a good join order,
 Tom> causing the join order to match the syntactic structure of the
 Tom> FROM clause. For instance "FROM a,b,c" will always be done by
 Tom> joining a to b first

FROM a,b,c can always be planned in any join order. If you want to force
the join order you have to set join_collapse_limit=1 AND write it as
FROM a JOIN b ON ... JOIN c ON ...

For an example, try:

explain select * from onek o1, tenk1 t, onek o2
         where o1.unique1=t.unique1 and t.unique1=o2.unique1
           and o1.unique2<10 and o2.unique2<10;

which (at least for me) joins o1 and o2 together first even with the
collapse limits set to 1.

-- 
Andrew (irc:RhodiumToad)



В списке pgsql-general по дате отправления:

Предыдущее
От: Andrew Gierth
Дата:
Сообщение: Re: Measuring the Query Optimizer Effect: Turning off the QO?
Следующее
От: John Lumby
Дата:
Сообщение: Re: REINDEX : new parameter to preserve current average leaf densityas new implicit FILLFACTOR