> On Fri, May 22, 2020 at 08:40:17AM +1200, David Rowley wrote: > > 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.
Yep, I'm onboard with the idea. > For Skipscans, that patch must expand on UniqueKeys to teach Paths > about them. That's already there. > I imagine we'll set some required UniqueKeys during > standard_qp_callback() In standard_qp_callback, because pathkeys are computed at this point I guess? > 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(). For a simple distinct query those UniqueKeys would be set based on distinct clause. If I understand correctly, the very same is implemented right now in create_distinct_paths, just after building all index paths, so wouldn't it be just a duplication? In general UniqueKeys in the skip scan patch were created from distinctClause in build_index_paths (looks similar to what you've described) and then based on them created index skip scan paths. So my expectations were that the patch from this thread would work similar.
