| 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: | Whole Thread | Raw Message | 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/)
| 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 |