From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Clarifying/rationalizing Vars' varno/varattno/varnoold/varoattno |
Date: | 2019-12-21 00:19:10 |
Message-ID: | 20191221001910.dx6hn7fkblwj2uau@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-12-20 11:12:53 -0500, Tom Lane wrote:
> (2) Explicitly mark Vars as being nullable by some outer join. I think
> we could probably get this down to one additional integer field in
> struct Var, so it wouldn't be too much of a penalty.
I've for a while wished that we could, e.g. so execution can use faster
tuple deforming code, infer nullability of columns above the scan
level. Right now there's no realistic way ExecTypeFromTL() can figure
that out, for upper query nodes. If we were to introduce something like
the field you suggest, it'd be darn near trivial.
OTOH, I'd really at some point like to start moving TupleDesc
computations to the planner - they're quite expensive, and we do them
over and over again. And that would not necessarily need a convenient
execution time representation anymore. But I don't think moving
tupledesc computation into the planner is a small rearrangement...
Would we want to have only boolean state, or more information (e.g. not
null, maybe null, is null)?
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Mark Lorenz | 2019-12-21 00:37:57 | Re: Created feature for to_date() conversion using patterns 'YYYY-WW', 'YYYY-WW-D', 'YYYY-MM-W' and 'YYYY-MM-W-D' |
Previous Message | Mark Lorenz | 2019-12-21 00:15:07 | Re: Created feature for to_date() conversion using patterns 'YYYY-WW', 'YYYY-WW-D', 'YYYY-MM-W' and 'YYYY-MM-W-D' |