RE: Index Skip Scan (new UniqueKeys)

Поиск
Список
Период
Сортировка
От Floris Van Nee
Тема RE: Index Skip Scan (new UniqueKeys)
Дата
Msg-id fb18ee881ea24d31b5272b4e5053a6aa@opammb0561.comp.optiver.com
обсуждение исходный текст
Ответ на Re: Index Skip Scan (new UniqueKeys)  (Dmitry Dolgov <9erthalion6@gmail.com>)
Ответы Re: Index Skip Scan (new UniqueKeys)  (Dmitry Dolgov <9erthalion6@gmail.com>)
Список pgsql-hackers
Hi Dmitry,

Also took another look at the patch now, and found a case of incorrect data. It looks related to the new way of
creatingthe 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)


With the 'order by a, b desc, c' we expect the value of column 'b' to always be 100. With index_skipscan enabled, it
alwaysgives 1 though. It's not correct that the planner chooses a skip scan followed by sort in this case. 

-Floris




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

Предыдущее
От: Justin Pryzby
Дата:
Сообщение: Re: expose parallel leader in CSV and log_line_prefix
Следующее
От: Mark Dilger
Дата:
Сообщение: Re: factorial function/phase out postfix operators?