Re: Use extended statistics to estimate (Var op Var) clauses

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

In response to

Responses

Browse pgsql-hackers by date

  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