From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com> |
Cc: | Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Use extended statistics to estimate (Var op Var) clauses |
Date: | 2022-07-09 12:04:57 |
Message-ID: | CAEZATCVFQw7bpv+YyQT+q+2VYMsXcSkwBL-MzQkjO==V+-HwiA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, 13 Dec 2021 at 02:21, Tomas Vondra
<tomas(dot)vondra(at)enterprisedb(dot)com> wrote:
>
> Hi,
>
> I finally got around to this patch again, focusing mostly on the first
> part that simply returns either 1.0 or 0.0 for Var op Var conditions
> (i.e. the part not really using extended statistics).
>
Just starting to look at this again, starting with 0001 ...
This needs to account for nullfrac, since x = x is only true if x is not null.
I don't like how matching_restriction_variables() is adding a
non-trivial amount of overhead to each of these selectivity functions,
by calling examine_variable() for each side, duplicating what
get_restriction_variable() does later on.
I think it would probably be better to make the changes in
var_eq_non_const(), where all of this information is available, and
get rid of matching_restriction_variables() (it doesn't look like the
new scalarineqsel_wrapper() code really needs
matching_restriction_variables() - it can just use what
get_restriction_variable() already returns).
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Dean Rasheed | 2022-07-09 12:17:53 | Re: Making the subquery alias optional in the FROM clause |
Previous Message | Zhihong Yu | 2022-07-09 11:30:32 | Re: Making the subquery alias optional in the FROM clause |