Re: Index Skip Scan

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: Index Skip Scan
Дата
Msg-id 20200208131159.5sjcbcjnwdj4q7fa@development
обсуждение исходный текст
Ответ на Re: Index Skip Scan  (Dmitry Dolgov <9erthalion6@gmail.com>)
Ответы Re: Index Skip Scan  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Список pgsql-hackers
On Fri, Feb 07, 2020 at 05:25:43PM +0100, Dmitry Dolgov wrote:
>> 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.

IMO the proper fix for this case (moving forward, reading backwards) is
simply making it work by properly checking deleted tuples etc. Not sure
why that would be so much complex (haven't tried implementing it)?

I think making this depend on things like declared cursor etc. is going
to be tricky, may easily be more complex than checking deleted tuples,
and the behavior may be quite surprising.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: legrand legrand
Дата:
Сообщение: Re: POC: rational number type (fractions)
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: Marking some contrib modules as trusted extensions