Re: Index Skip Scan (new UniqueKeys)

Поиск
Список
Период
Сортировка
От Dmitry Dolgov
Тема Re: Index Skip Scan (new UniqueKeys)
Дата
Msg-id 20200711162103.hiygat3k6wu2d25p@localhost
обсуждение исходный текст
Ответ на RE: Index Skip Scan (new UniqueKeys)  (Floris Van Nee <florisvannee@Optiver.com>)
Ответы RE: Index Skip Scan (new UniqueKeys)  (Floris Van Nee <florisvannee@Optiver.com>)
Список pgsql-hackers
> On Fri, Jul 10, 2020 at 05:03:37PM +0000, Floris Van Nee wrote:
>
> Also took another look at the patch now, and found a case of incorrect
> data. It looks related to the new way of creating the paths, as I
> can't recall seeing this in earlier versions.
>
> create table t1 as select a,b,b%5 as c, random() as d from generate_series(1, 10) a, generate_series(1,100) b;
> create index on t1 (a,b,c);
>
> postgres=# explain select distinct on (a) * from t1 order by a,b desc,c;
>                                   QUERY PLAN
> -------------------------------------------------------------------------------
>  Sort  (cost=2.92..2.94 rows=10 width=20)
>    Sort Key: a, b DESC, c
>    ->  Index Scan using t1_a_b_c_idx on t1  (cost=0.28..2.75 rows=10 width=20)
>          Skip scan: true
> (4 rows)

Good point, thanks for looking at this. With the latest planner version
there are indeed more possibilities to use skipping. It never occured to
me that some of those paths will still rely on index scan returning full
data set. I'll look in details and add verification to prevent putting
something like this on top of skip scan in the next version.



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

Предыдущее
От: Dmitry Dolgov
Дата:
Сообщение: Re: Index Skip Scan (new UniqueKeys)
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"