Re: Index Skip Scan
От | Dmitry Dolgov |
---|---|
Тема | Re: Index Skip Scan |
Дата | |
Msg-id | 20200207162543.zlj2tvcwy7jku6vu@localhost обсуждение исходный текст |
Ответ на | Re: Index Skip Scan (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Ответы |
Re: Index Skip Scan
Re: Index Skip Scan Re: Index Skip Scan |
Список | pgsql-hackers |
> On Thu, Feb 06, 2020 at 09:22:20PM +0900, Kyotaro Horiguchi wrote: > At Thu, 6 Feb 2020 11:57:07 +0100, Dmitry Dolgov <9erthalion6@gmail.com> wrote in > > > On Thu, Feb 06, 2020 at 10:24:50AM +0900, Kyotaro Horiguchi wrote: > > > At Wed, 5 Feb 2020 17:37:30 +0100, Dmitry Dolgov <9erthalion6@gmail.com> wrote in > > > We could add an additional parameter "in_cursor" to > > > ExecSupportBackwardScan and let skip scan return false if in_cursor is > > > true, but I'm not sure it's acceptable. > > > > I also was thinking about whether it's possible to use > > ExecSupportBackwardScan here, but skip scan is just a mode of an > > index/indexonly scan. Which means that ExecSupportBackwardScan also need > > to know somehow if this mode is being used, and then, since this > > function is called after it's already decided to use skip scan in the > > resulting plan, somehow correct the plan (exclude skipping and try to > > find next best path?) - do I understand your suggestion correct? > > I didn't thought so hardly, but a bit of confirmation told me that > IndexSupportsBackwardScan returns fixed flag for AM. It seems that > things are not that simple. Yes, I've mentioned that already in one of the previous emails :) The simplest way I see to achieve what we want is to do something like in attached modified version with a new hasDeclaredCursor field. It's not a final version though, but posted just for discussion, so feel free to suggest any improvements or alternatives.
Вложения
В списке pgsql-hackers по дате отправления: