Re: Understanding bad estimate (related to FKs?) - Mailing list pgsql-performance

From Philip Semanchuk
Subject Re: Understanding bad estimate (related to FKs?)
Date
Msg-id 553742C5-85E6-48C1-997F-3BFE2FD81FC4@americanefficient.com
Whole thread Raw
In response to Re: Understanding bad estimate (related to FKs?)  (Michael Lewis <mlewis@entrata.com>)
List pgsql-performance

> On Oct 26, 2020, at 1:20 PM, Michael Lewis <mlewis@entrata.com> wrote:
>
> On Mon, Oct 26, 2020 at 11:14 AM Philip Semanchuk <philip@americanefficient.com> wrote:
> >> The item I'm focused on is node 23. The estimate is for 7 rows, actual is 896 (multiplied by 1062 loops). I'm
confusedabout two things in this node. 
> >>
> >> The first is Postgres' estimate. The condition for this index scan contains three expressions --
> >>
> >> (five_uniform = zulu_five.five_uniform) AND
> >> (whiskey_mike = juliet_india.whiskey_mike) AND
> >> (bravo = 'mike'::text)
>
> Are the columns correlated? Have you tried to create extended statistics and see if the estimate changes? I believe
thatextended stats will not directly help with joins though, only group bys and perhaps choosing an index scan vs table
scanwhen comparing the correlated columns to static values rather than joining up tables. Wouldn't be much effort to
tryit though. 


There’s not a lot of correlation between whiskey_mike and bravo --
stxkind     stxndistinct    stxdependencies
['d', 'f']  {"7, 12": 42}   {"12 => 7": 0.000274}

Those stats didn’t help the planner.

I should have mentioned that five_uniform has ~63k unique values, whereas whiskey_mike has only 3, and bravo only 19.

Cheers
Philip


pgsql-performance by date:

Previous
From: Michael Lewis
Date:
Subject: Re: Understanding bad estimate (related to FKs?)
Next
From: Justin Pryzby
Date:
Subject: Re: Postgres Optimizer ignores information about foreign key relationship, severely misestimating number of returned rows in join