Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)

From: Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Dmitry Dolgov <9erthalion6(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, "Hou, Zhijie" <houzj(dot)fnst(at)cn(dot)fujitsu(dot)com>, Floris Van Nee <florisvannee(at)optiver(dot)com>
Subject: Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
Date: 2021-02-12 02:17:48
Message-ID: CAKU4AWobtkZV0SNHdVJ=VSpaLZK5tEBjPWmph9ZpMt9CQyiW_g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Thank you all, friends!

On Fri, Feb 12, 2021 at 9:02 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Wed, 10 Feb 2021 at 16:18, Andy Fan <zhihui(dot)fan1213(at)gmail(dot)com> wrote:
> > v1-0001-Introduce-notnullattrs-field-in-RelOptInfo-to-ind.patch
> >
> > Introduce notnullattrs field in RelOptInfo to indicate which attr are
> not null
> > in current query. The not null is judged by checking pg_attribute and
> query's
> > restrictinfo. The info is only maintained at Base RelOptInfo and
> Partition's
> > RelOptInfo level so far.
> >
> >
> > Any thoughts?
>
> I'm not that happy with what exactly the definition is of
> RelOptInfo.notnullattrs.
>
> The comment for the field says:
> + /* Not null attrs, start from -FirstLowInvalidHeapAttributeNumber */
>
> So you could expect someone to assume that these are a Bitmapset of
> attnums for all columns in the relation marked as NOT NULL. However,
> that's not true since you use find_nonnullable_vars() to chase down
> quals that filter out NULL values and you mark those too.
>
>
The comment might be unclear, but the behavior is on purpose. I want
to find more cases which can make the attr NOT NULL, all of them are
useful for UniqueKey stuff.

> The reason I don't really like this is that it really depends where
> you want to use RelOptInfo.notnullattrs. If someone wants to use it
> to optimise something before the base quals are evaluated then they
> might be unhappy that they found some NULLs.
>
>
Do you mean the notnullattrs is not set correctly before the base quals are
evaluated? I think we have lots of data structures which are set just
after some
stage. but notnullattrs is special because it is set at more than 1
stage. However
I'm doubtful it is unacceptable, Some fields ever change their meaning at
different
stages like Var->varno. If a user has a misunderstanding on it, it
probably will find it
at the testing stage.

> I think you either need to explain in detail what the field means or
> separate out the two meanings somehow.
>
>
Agreed. Besides the not null comes from 2 places (metadata and quals), it
also
means it is based on the relation, rather than the RelTarget. for sample:
A is not
null, but SELECT return_null_udf(A) FROM t, return_null_udf is NULL.
I think
this is not well documented as well. How about just change the documents
as:

1. /* Not null attrs, start from -FirstLowInvalidHeapAttributeNumber, the
NOT NULL
* comes from pg_attribtes and quals at different planning stages.
*/

or

2. /* Not null attrs, start from -FirstLowInvalidHeapAttributeNumber, the
NOT NULL
* comes from pg_attribtes and quals at different planning stages. And
it just means
* the base attr rather than RelOptInfo->reltarget.
*/

I don't like to separate them into 2 fields because it may make the usage
harder a
bit as well.
--
Best Regards
Andy Fan (https://www.aliyun.com/)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andy Fan 2021-02-12 02:31:32 Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
Previous Message Justin Pryzby 2021-02-12 01:48:37 pg13.2: invalid memory alloc request size NNNN