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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
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:29:28
Message-ID: 1831.1562603368@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "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.

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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Justin Pryzby 2019-07-08 16:44:01 OOM with many sorts
Previous Message John Lumby 2019-07-08 16:23:15 Re: REINDEX : new parameter to preserve current average leaf density as new implicit FILLFACTOR