Re: Clarifying/rationalizing Vars' varno/varattno/varnoold/varoattno - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Clarifying/rationalizing Vars' varno/varattno/varnoold/varoattno
Date
Msg-id 20191221001910.dx6hn7fkblwj2uau@alap3.anarazel.de
Whole thread Raw
In response to Re: Clarifying/rationalizing Vars' varno/varattno/varnoold/varoattno  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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



pgsql-hackers by date:

Previous
From: Mark Lorenz
Date:
Subject: Re: Created feature for to_date() conversion using patterns'YYYY-WW', 'YYYY-WW-D', 'YYYY-MM-W' and 'YYYY-MM-W-D'
Next
From: Mark Lorenz
Date:
Subject: Re: Created feature for to_date() conversion using patterns'YYYY-WW', 'YYYY-WW-D', 'YYYY-MM-W' and 'YYYY-MM-W-D'