Re: New design for FK-based join selectivity estimation

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: New design for FK-based join selectivity estimation
Дата
Msg-id 13294.1466278050@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: New design for FK-based join selectivity estimation  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы 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>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: New design for FK-based join selectivity estimation
Следующее
От: Tom Lane
Дата:
Сообщение: Rethinking behavior of force_parallel_mode = regress