Re: Clarifying/rationalizing Vars' varno/varattno/varnoold/varoattno

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

In response to

Browse pgsql-hackers by date

  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'