Re: Index Skip Scan
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Index Skip Scan |
Дата | |
Msg-id | 77321c30-0d6b-3975-0a2f-40f28691a334@gmail.com обсуждение исходный текст |
Ответ на | Re: Index Skip Scan (Kyotaro Horiguchi <horikyota.ntt@gmail.com>) |
Список | pgsql-hackers |
Sorry, I forgot to write more significant thing. On 2020/02/06 21:22, 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? No. I thought of the opposite thing. I meant that IndexSupportsBackwardScan returns false if Index(Only)Scan is going to do skip scan. But I found that the function doesn't have access to plan node nor executor node. So I wrote as the follows. >> 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. regards. -- Kyotaro Horiguchi
В списке pgsql-hackers по дате отправления: