Re: Index Skip Scan

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: Index Skip Scan
Дата
Msg-id CA+q6zcVVigO_1KRBxvzKfnR593CEE7FKR-bwP-XcH6AVHOo4+g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Index Skip Scan  (Dmitry Dolgov <9erthalion6@gmail.com>)
Ответы Re: Index Skip Scan  (Jesper Pedersen <jesper.pedersen@redhat.com>)
Re: Index Skip Scan  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
> On Sun, Jun 16, 2019 at 5:03 PM Dmitry Dolgov <9erthalion6@gmail.com> wrote:
>
> > I also agree with James that this should not be limited to Index Only
> > Scans. From testing the patch, the following seems pretty strange to
> > me:
> > ...
> > explain analyze select distinct on (a) a,b from abc order by a,b;
> > explain analyze select distinct on (a) a,b,c from abc order by a,b;
> > ...
>
> Yes, but I believe this limitation is not intrinsic to the idea of the patch,
> and the very same approach can be used for IndexScan in the second example.
> I've already prepared a new version to enable it for IndexScan with minimal
> modifications, just need to rebase it on top of the latest changes and then
> can post it. Although still there would be some limitations I guess (e.g. the
> first thing I've stumbled upon is that an index scan with a filter wouldn't
> work well, because checking qual causes with a filter happens after
> ExecScanFetch)

Here is what I was talking about, POC for an integration with index scan. About
using of create_skipscan_unique_path and suggested planner improvements, I hope
together with Jesper we can come up with something soon.

Вложения

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

Предыдущее
От: Binguo Bao
Дата:
Сообщение: [proposal] de-TOAST'ing using a iterator
Следующее
От: Oleksii Kliukin
Дата:
Сообщение: Re: pgsql: Avoid spurious deadlocks when upgrading a tuple lock