Re: Use zero for nullness estimates of system attributes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Use zero for nullness estimates of system attributes
Date
Msg-id 30588.1548435054@sss.pgh.pa.us
Whole thread Raw
In response to Use zero for nullness estimates of system attributes  (Edmund Horner <ejrh00@gmail.com>)
Responses Re: Use zero for nullness estimates of system attributes  (Jim Finnerty <jfinnert@amazon.com>)
List pgsql-hackers
Edmund Horner <ejrh00@gmail.com> writes:
> I added some code to selfuncs.c to estimate the selectivity of CTID,
> including nullness, in my ongoing attempt to add TID range scans [1].  And
> as Tom pointed out [2], no system attribute can be null, so we might as
> well handle them all.
> That's what the attached patch does.

Seems pretty uncontroversial, so pushed.

> I observed a few interesting things with outer join selectivity:
> While system attributes aren't NULL in the table, they can be in queries
> such as:

Yeah, none of our selectivity calculations account for the possibility
that we're above a join that has affected the distribution of a Var's
values.  Going to NULL in an outer join is just part of that issue.
I don't feel this patch needs to solve it, and anyway it'd be a rather
massive rethink.

> Finally: I thought about introducing a macro to attnum.h:
>     #define AttrNumberIsForSystemAttr(attributeNumber) \
>      ((bool) ((attributeNumber) < 0))
> But there's a zillion places that could be changed to use it, so I haven't
> in this version of the patch.

I can't get too excited about that.  Even if the reader is unfamiliar with
the negative-attno convention, most of these places are commented in a way
that makes it clear what's going on.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Fabien COELHO
Date:
Subject: Re: Alternative to \copy in psql modelled after \g
Next
From: Alvaro Herrera
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions