Re: [PATCH] Keeps tracking the uniqueness with UniqueKey

On Fri, May 22, 2020 at 4:40 AM David Rowley <dgrowleyml(at)gmail(dot)com> wrote:

> On Fri, 22 May 2020 at 07:49, Dmitry Dolgov <9erthalion6(at)gmail(dot)com> wrote:
> > * It seems populate_baserel_uniquekeys, which actually sets uniquekeys,
> > is called after create_index_paths, where index skip scan already
> > needs to use them. Is it possible to call it earlier?
>
> Seems reasonable. I originally put it after check_index_predicates().
> We need to wait until at least then so we can properly build
> UniqueKeys for partial indexes.
>
>
Looks a very valid reason, I will add this in the next version.

> > * Do I understand correctly, that a UniqueKey would be created in a
> > simplest case only when an index is unique? This makes it different
> > from what was implemented for index skip scan, since there UniqueKeys
> > also represents potential to use non-unique index to facilitate search
> > for unique values via skipping.
>
> The way I picture the two working together is that the core UniqueKey
> patch adds UniqueKeys to RelOptInfos to allow us to have knowledge
> about what they're unique on based on the base relation's unique
> indexes.
>
For Skipscans, that patch must expand on UniqueKeys to teach Paths
> about them. I imagine we'll set some required UniqueKeys during
> standard_qp_callback() and then we'll try to create some Skip Scan
> paths (which are marked with UniqueKeys) if the base relation does not
> already have UniqueKeys that satisfy the required UniqueKeys that were
> set during standard_qp_callback(). In the future, there may be other
> reasons to create Skip Scan paths for certain rels, e.g if they're on
> the inner side of a SEMI/ANTI join, it might be useful to try those
> when planning joins.
>
>
Yes, In current implementation, we also add UniqueKey during
create_xxx_paths,
xxx may be grouping/union. after the index skipscan patch, we can do the
similar
things in create_indexskip_path.

--
Best Regards
Andy Fan