On Fri, May 22, 2020 at 4:40 AM David Rowley <dgrowle...@gmail.com> wrote:
> On Fri, 22 May 2020 at 07:49, Dmitry Dolgov <9erthali...@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 things in create_indexskip_path. -- Best Regards Andy Fan
