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 по дате отправления: