From: | Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Tom Mercha <mercha_t(at)hotmail(dot)com>, "pgsql-general\(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Measuring the Query Optimizer Effect: Turning off the QO? |
Date: | 2019-07-08 16:14:51 |
Message-ID: | 87muho5x24.fsf@news-spur.riddles.org.uk |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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)
From | Date | Subject | |
---|---|---|---|
Next Message | John Lumby | 2019-07-08 16:23:15 | Re: REINDEX : new parameter to preserve current average leaf density as new implicit FILLFACTOR |
Previous Message | Andrew Gierth | 2019-07-08 14:23:34 | Re: Measuring the Query Optimizer Effect: Turning off the QO? |