Re: New design for FK-based join selectivity estimation - Mailing list pgsql-hackers

From Tom Lane
Subject Re: New design for FK-based join selectivity estimation
Date
Msg-id 13294.1466278050@sss.pgh.pa.us
Whole thread Raw
In response to Re: New design for FK-based join selectivity estimation  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: New design for FK-based join selectivity estimation  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: [HACKERS] New design for FK-based join selectivity estimation  (Adrien Nayrat <adrien.nayrat@dalibo.com>)
List pgsql-hackers
I wrote:
> Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
>> Is this a good idea? I'd probably vote to do what's proposed (and 
>> rejected) in the second half of the comment, i.e. put back the clauses 
>> and skip the FK as that pretty much says "improve estimate or keep the 
>> current one, but don't risk making it worse."

> I would buy that approach when it comes to "loose" quals, but I think
> it's not right for EC-derived matches, because of the behavior we
> discussed previously that an EC should be considered to have implicitly
> generated all the matching quals even though it actually made only one
> qual that might not be any of them exactly.

After further thought I decided you're right, because one of the main
original goals of ECs was to prevent double-counting the selectivity
of redundant equality quals.  Acting as though the EC had generated
multiple redundant quals is likely to make things worse not better.

I still feel that we're leaving something on the table here, but it
would need to take the form of intelligently combining estimates for
overlapping FKs, not just blindly multiplying them together.  Seems
like a task for later, especially considering that cases of this sort
are likely to be rare.

Pushed with adjustments for that.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: New design for FK-based join selectivity estimation
Next
From: Tom Lane
Date:
Subject: Rethinking behavior of force_parallel_mode = regress