Re: Understanding bad estimate (related to FKs?)

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

In response to

Browse pgsql-performance by date

  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