>
> Hm, I wasn't aware about this one, thanks for bringing this up. Btw, Floris, I
> would appreciate if in the future you can make it more visible that changes you
> suggest contain some fixes. E.g. it wasn't clear for me from your previous email
> that that's the case, and it doesn't make sense to pull into different direction
> when we're trying to achieve the same goal :)
I wasn't aware that this particular case could be triggered before I saw Dilip's email, otherwise I'd have mentioned it
hereof course. It's just that because my patch handles filter conditions in general, it works for this case too.
>
> > > In the patch I posted a week ago these cases are all handled
> > > correctly, as it introduces this extra logic in the Executor.
> >
> > Okay, So I think we can merge those fixes in Dmitry's patch set.
>
> I'll definitely take a look at suggested changes in filtering part.
It may be possible to just merge the filtering part into your patch, but I'm not entirely sure. Basically you have to
pullthe information about skipping one level up, out of the node, into the generic IndexNext code.
I'm eager to get some form of skip scans into master - any kind of patch that makes this possible is fine by me. Long
termI think my version provides a more generic approach, with which we can optimize a much broader range of queries.
However,since many more eyes have seen your patch so far, I hope yours can be committed much sooner. My knowledge on
thiscommitter process is limited though. That's why I've just posted mine so far in the hope of collecting some
feedback,also on how we should continue with the process.
-Floris