From: | Tom Mercha <mercha_t(at)hotmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> |
Cc: | "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 19:17:00 |
Message-ID: | AM6PR04MB554441D0E2A76EF44C546421F4F60@AM6PR04MB5544.eurprd04.prod.outlook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 08/07/2019 18:29, Tom Lane wrote:
> 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
>
Thanks for the clarification. I really appreciate taking the time to
provide such in depth info about my query!
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-07-08 19:19:03 | Re: REINDEX : new parameter to preserve current average leaf density as new implicit FILLFACTOR |
Previous Message | John Lumby | 2019-07-08 19:10:54 | Re: REINDEX : new parameter to preserve current average leaf density as new implicit FILLFACTOR |