Re: Index Skip Scan
| От | Floris Van Nee |
|---|---|
| Тема | Re: Index Skip Scan |
| Дата | |
| Msg-id | 1559362223126.18661@Optiver.com обсуждение исходный текст |
| Ответ на | Re: Index Skip Scan (Floris Van Nee <florisvannee@Optiver.com>) |
| Ответы |
Re: Index Skip Scan
Re: Index Skip Scan Re: Index Skip Scan |
| Список | pgsql-hackers |
Actually I'd like to add something to this. I think I've found a bug in the current implementation. Would someone be able to check?
Given a table definition of (market text, feedcode text, updated_at timestamptz, value float8) and an index on (market, feedcode, updated_at desc) (note that this table slightly deviates from what I described in my previous mail) and filling it with data.
The following query uses an index skip scan and returns just 1 row (incorrect!)
select distinct on (market, feedcode) market, feedcode
from streams.base_price
where market='TEST'
The following query still uses the regular index scan and returns many more rows (correct)
select distinct on (market, feedcode) *
from streams.base_price
where market='TEST'
It seems that partially filtering on one of the distinct columns triggers incorrect behavior where too many rows in the index are skipped.
-Floris
В списке pgsql-hackers по дате отправления: