Re: Index Skip Scan (new UniqueKeys) - Mailing list pgsql-hackers

From Dmitry Dolgov
Subject Re: Index Skip Scan (new UniqueKeys)
Date
Msg-id 20200711162103.hiygat3k6wu2d25p@localhost
Whole thread Raw
In response to RE: Index Skip Scan (new UniqueKeys)  (Floris Van Nee <florisvannee@Optiver.com>)
Responses RE: Index Skip Scan (new UniqueKeys)  (Floris Van Nee <florisvannee@Optiver.com>)
List 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 by date:

Previous
From: Dmitry Dolgov
Date:
Subject: Re: Index Skip Scan (new UniqueKeys)
Next
From: Mark Dilger
Date:
Subject: Re: Towards easier AMs: Cleaning up inappropriate use of name "relkind"