Re: Index Skip Scan (new UniqueKeys)

> On Sat, Dec 05, 2020 at 06:55:42PM +0100, Dmitry Dolgov wrote:
> > On Tue, Dec 01, 2020 at 10:59:22PM +0200, Heikki Linnakangas wrote:
> >
> > > > - Does this optimization apply to bitmap index scans?
> > >
> > > No, from what I understand it doesn't.
> >
> > Would it be hard to add? Don't need to solve everything in the first
> > version of this, but I think in principle you could do the same
> > optimization for bitmap index scans, so if the current API can't do it,
> > that's maybe an indication that the API isn't quite right.
>
> I would expect it should not be hard as at the moment all parts seems
> relatively generic. But of course I need to check, while it seems no one
> had bitmap index scans in mind while developing this patch.
>
> On Sun, Dec 06, 2020 at 09:27:08AM +1300, Thomas Munro wrote:
>
> FWIW here's what I wrote about that years ago[1]:
> [1] https://www.postgresql.org/message-id/CADLWmXWALK8NPZqdnRQiPnrzAnic7NxYKynrkzO_vxYr8enWww%40mail.gmail.com

Thanks, that clarifies this topic a bit.

> > If you care whether the qual is evaluated by the index AM or not, you need
> > to also check that the operator is indexable. Attached is a query that
> > demonstrates that problem.
> > ...
> > Also, you should probably check that the index quals are in the operator
> > family as that used for the DISTINCT.
>
> Yes, good point, will change this in the next version.

Sorry for such long silence, now I've got a bit of free time after
subscripting patch to work on this one. Here is rebased version with a
few changes to address Heikki feedback about checking if the qual
operator is indexable. But...

This version is based on the old version of UniqueKey patch (first two
attached patches), mostly because IIUC there is still no final version
of it ([1], [2]). This means index skip scan could be reviewed and
discussed (and I'm planning to review the current design to see if it's
possible to improve it in the view of the latest changes), but
independently of the UniqueKey integration as it's subject to change.
But I'm afraid if things will go as it is and there will be not much
progress with the UniqueKey patch, I will have to withdraw this one
until everything is sorted out there.

[1]: https://www.postgresql.org/message-id/flat/CAKU4AWpQjAqJwQ2X-aR9g3+ZHRzU1k8hNP7A+_mLuOv-n5aVKA(at)mail(dot)gmail(dot)com
[2]: https://www.postgresql.org/message-id/flat/CAKU4AWrU35c9g3cE15JmVwh6B2Hzf4hf7cZUkRsiktv7AKR3Ag(at)mail(dot)gmail(dot)com