On Wed, 11 Mar 2020 at 16:44, Andy Fan <zhihui.fan1213@gmail.com> wrote:
>>
>>
>> I think the UniqueKeys may need to be changed from using
>> EquivalenceClasses to use Exprs instead.
>
>
> When I try to understand why UniqueKeys needs EquivalenceClasses,
> see your comments here. I feel that FuncExpr can't be
> used to as a UniquePath even we can create unique index on f(a)
> and f->strict == true. The reason is even we know a is not null,
> f->strict = true. it is still be possible that f(a) == null. unique index
> allows more than 1 null values. so shall we move further to use varattrno
> instead of Expr? if so, we can also use a list of Bitmapset to present multi
> unique path of a single RelOptInfo.
We do need some method to determine if NULL values are possible. At
the base relation level that can probably be done by checking NOT NULL
constraints and strict base quals. At higher levels, we can use strict
join quals as proofs.
As for bit a Bitmapset of varattnos, that would certainly work well at
the base relation level when there are no unique expression indexes,
but it's not so simple with join relations when the varattnos only
mean something when you know which base relation it comes from. I'm
not saying that Lists of Exprs is ideal, but I think trying to
optimise some code that does not yet exist is premature.
There was some other talk in [1] on how we might make checking if a
List contains a given Node. That could be advantageous in a few
places in the query planner, and it might be useful for this too.
[1] https://www.postgresql.org/message-id/CAKJS1f8v-fUG8YpaAGj309ZuALo3aEk7f6cqMHr_AVwz1fKXug%40mail.gmail.com
