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

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
Дата
Msg-id CAApHDvqxpkmediXdc-5-6tzTtStn_y6N_PkCe7v9FP8bNdBZLA@mail.gmail.com
обсуждение исходный текст
Ответ на Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)  (Andy Fan <zhihui.fan1213@gmail.com>)
Ответы Re: Keep notnullattrs in RelOptInfo (Was part of UniqueKey patch series)
Список pgsql-hackers
On Wed, 10 Feb 2021 at 16:18, Andy Fan <zhihui.fan1213@gmail.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 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.

I think you either need to explain in detail what the field means or
separate out the two meanings somehow.

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: WIP: WAL prefetch (another approach)
Следующее
От: "iwata.aya@fujitsu.com"
Дата:
Сообщение: RE: libpq debug log