> On Mon, Jul 22, 2019 at 7:10 PM Jesper Pedersen <jesper.peder...@redhat.com> > wrote: > > On 7/22/19 1:44 AM, David Rowley wrote: > > Here are the comments I noted down during the review: > > > > cost_index: > > > > I know you've not finished here, but I think it'll need to adjust > > tuples_fetched somehow to account for estimate_num_groups() on the > > Path's unique keys. Any Eclass with an ec_has_const = true does not > > need to be part of the estimate there as there can only be at most one > > value for these. > > > > For example, in a query such as: > > > > SELECT x,y FROM t WHERE x = 1 GROUP BY x,y; > > > > you only need to perform estimate_num_groups() on "y". > > > > I'm really not quite sure on what exactly will be required from > > amcostestimate() here. The cost of the skip scan is not the same as > > the normal scan. So other that API needs adjusted to allow the caller > > to mention that we want skip scans estimated, or there needs to be > > another callback. > > > > I think this part will become more clear once the index skip scan patch > is rebased, as we got the uniquekeys field on the Path, and the > indexskipprefixy info on the IndexPath node.
Here is what I came up with to address the problems, mentioned above in this thread. It passes tests, but I haven't tested it yet more thoughtful (e.g. it occurred to me, that `_bt_read_closest` probably wouldn't work, if a next key, that passes an index condition is few pages away - I'll try to tackle it soon). Just another small step forward, but I hope it's enough to rebase on top of it planner changes. Also I've added few tags, mostly to mention reviewers contribution.
v22-0001-Index-skip-scan.patch
Description: Binary data
