From: | Philip Semanchuk <philip(at)americanefficient(dot)com> |
---|---|
To: | Michael Lewis <mlewis(at)entrata(dot)com> |
Cc: | Guillaume Lelarge <guillaume(at)lelarge(dot)info>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, postgres performance list <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Understanding bad estimate (related to FKs?) |
Date: | 2020-11-03 15:07:24 |
Message-ID: | BCDDA7C9-7999-4BFF-BDCA-7BF5E28A051C@americanefficient.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> On Nov 2, 2020, at 6:09 PM, Michael Lewis <mlewis(at)entrata(dot)com> wrote:
>
> The query I asked about in the original post of this thread has 13 relations in it. IIUC, that's 13! or > 6 billion possible plans. How did the planner pick one plan out of 6 billion? I'm curious, both for practical purposes (I want my query to run well) and also because it's fascinating.
>
> Have you increased geqo_threshold and join_collapse_limit from the defaults?
Yes, thanks you, I should have said that. We avoid the GEQO, so geqo_threshold=25, and join_collapse_limit=from_collapse_limit=24. We tend to have long running queries, so we’re happy to pay a few seconds of extra planner cost to increase the likelihood of getting a better plan.
Cheers
Philip
From | Date | Subject | |
---|---|---|---|
Next Message | Philip Semanchuk | 2020-11-03 15:27:38 | Re: Understanding bad estimate (related to FKs?) |
Previous Message | Ehrenreich, Sigrid | 2020-11-03 13:20:10 | Partition pruning with joins |