Re: Measuring the Query Optimizer Effect: Turning off the QO?
От | Tom Lane |
---|---|
Тема | Re: Measuring the Query Optimizer Effect: Turning off the QO? |
Дата | |
Msg-id | 1831.1562603368@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Measuring the Query Optimizer Effect: Turning off the QO? (Andrew Gierth <andrew@tao11.riddles.org.uk>) |
Ответы |
Re: Measuring the Query Optimizer Effect: Turning off the QO?
|
Список | pgsql-general |
Andrew Gierth <andrew@tao11.riddles.org.uk> writes: > "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. Ah, right, -ENOCAFFEINE. What from_collapse_limit really does is prevent flattening sub-SELECTs when doing so would add more join-order freedom in the parent query. But ignoring sub-SELECTs, using explicit JOIN syntax with join_collapse_limit=1 will let you control the join order. regards, tom lane
В списке pgsql-general по дате отправления: