On Fri, 22 May 2020 at 07:49, Dmitry Dolgov <9erthalion6@gmail.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