Re: Evaluate expression at planning time for two more cases - Mailing list pgsql-hackers

From David Rowley
Subject Re: Evaluate expression at planning time for two more cases
Date
Msg-id CAApHDvrbraMnmnoWdTUziuXDfXXOfhxDTkcoWG8i4CmA13=PaA@mail.gmail.com
Whole thread Raw
In response to Evaluate expression at planning time for two more cases  (Surafel Temesgen <surafel3000@gmail.com>)
Responses Re: Evaluate expression at planning time for two more cases
List pgsql-hackers
On Tue, 9 Mar 2021 at 05:13, Ibrar Ahmed <ibrar.ahmad@gmail.com> wrote:
> It was a minor change therefore I rebased the patch, please take a look.

I only had a quick look at the v3 patch.

+ rel = table_open(rte->relid, NoLock);
+ att = TupleDescAttr(rel->rd_att, var->varattno - 1);

+ if (att->attnotnull && !check_null_side(context->root, relid, context))

This is not really an acceptable way to determine the notnull
attribute value. Andy Fan proposes a much better way in [1].
RelOptInfo is meant to cache the required Relation data that we need
during query planning. IIRC, Andy's patch correctly uses this and does
so in an efficient way.

In any case, as you can see there's a bit of other work going on to
smarten up the planner around NULL value detection. The UniqueKeys
patch requires this and various other things have come up that really
should be solved.

Surafel, I'd suggest we return this patch with feedback and maybe you
could instead help reviewing the other patches in regards to the NOT
NULL tracking and maybe come back to this once the dust has settled
and everyone is clear on how we determine if a column is NULL or not.

Let me know your thoughts.

David

[1] https://www.postgresql.org/message-id/CAKU4AWpQjAqJwQ2X-aR9g3+ZHRzU1k8hNP7A+_mLuOv-n5aVKA@mail.gmail.com



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: Evaluate expression at planning time for two more cases
Next
From: "houzj.fnst@fujitsu.com"
Date:
Subject: RE: [bug?] Missed parallel safety checks, and wrong parallel safety