On 11/18/18 02:27, Dmitry Dolgov wrote:
>
> [0001-Index-skip-scan-v4.patch]
I ran a couple of tests on this, please see the cases below. As before,
I'm setting total_cost = 1 for index skip scan so that it is chosen.
Case 1 breaks because we determine the high key incorrectly, it is the
second tuple on page or something like that, not the last tuple. Case 2
is backwards scan, I don't understand how it is supposed to work. We
call _bt_search(nextKey = ScanDirectionIsForward), so it seems that it
just fetches the previous tuple like the regular scan does.
case 1:
# create table t as select generate_series(1, 1000000) a;
# create index ta on t(a);
# explain select count(*) from (select distinct a from t) d;
QUERY PLAN
-------------------------------------------------------------------------
Aggregate (cost=3.50..3.51 rows=1 width=8)
-> Index Only Scan using ta on t (cost=0.42..1.00 rows=200 width=4)
Scan mode: Skip scan
(3 rows)
postgres=# select count(*) from (select distinct a from t) d;
count
--------
500000 -- should be 1kk
(1 row)
case 2:
# create table t as select generate_series(1, 1000000) / 2 a;
# create index ta on t(a);
# explain select count(*) from (select distinct a from t order by a desc) d;
QUERY PLAN
-------------------------------------------------------------------------------------
Aggregate (cost=5980.81..5980.82 rows=1 width=8)
-> Index Only Scan Backward using ta on t (cost=0.42..1.00
rows=478385 width=4)
Scan mode: Skip scan
(3 rows)
# select count(*) from (select distinct a from t order by a desc) d;
count
--------
502733 -- should be 500k
(1 row)
--
Alexander Kuzmenkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company