Re: Index Skip Scan

Поиск
Список
Период
Сортировка
От Alvaro Herrera from 2ndQuadrant
Тема Re: Index Skip Scan
Дата
Msg-id 20190905194128.GA10752@alvherre.pgsql
обсуждение исходный текст
Ответ на Index Skip Scan  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Ответы Re: Index Skip Scan  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список pgsql-hackers
On 2019-Sep-05, Dmitry Dolgov wrote:

> Here is the version in which stepping between the pages works better. It seems
> sufficient to fix the case you've mentioned before, but for that we need to
> propagate keepPrev logic through `_bt_steppage` & `_bt_readnextpage`, and I
> can't say I like this solution. I have an idea that maybe it would be simpler
> to teach the code after index_skip to not do `_bt_next` right after one skip
> happened before. It should immediately elliminate several hacks from index skip
> itself, so I'll try to pursue this idea.

Cool.

I think multiplying two ScanDirections to watch for a negative result is
pretty ugly:

        /*
         * If advancing direction is different from index direction, we must
         * skip right away, but _bt_skip requires a starting point.
         */
        if (direction * indexscan->indexorderdir < 0 &&
            !node->iss_FirstTupleEmitted)

Surely there's a better way to code that?

I think "scanstart" needs more documentation, both in the SGML docs as
well as the code comments surrounding it.

Please disregard my earlier comment about FirstTupleEmitted.  I was
thinking that index_skip would itself emit a tuple (ie. call some
"getnext" internally) rather than just repositioning.  There might still
be some more convenient way to represent this, but I have no immediate
advice.

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: tableam vs. TOAST
Следующее
От: Robert Haas
Дата:
Сообщение: Re: tableam vs. TOAST