From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Edmund Horner <ejrh00(at)gmail(dot)com> |
Cc: | PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Use zero for nullness estimates of system attributes |
Date: | 2019-01-25 16:50:54 |
Message-ID: | 30588.1548435054@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Edmund Horner <ejrh00(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2019-01-25 17:03:27 | Re: [HACKERS] logical decoding of two-phase transactions |
Previous Message | Fabien COELHO | 2019-01-25 16:43:38 | Re: Alternative to \copy in psql modelled after \g |