On Wed, Mar 25, 2020 at 2:19 PM Dmitry Dolgov <9erthali...@gmail.com> wrote:
>
> > On Wed, Mar 25, 2020 at 11:31:56AM +0530, Dilip Kumar wrote:
> >
> > Seems like you forgot to add the uniquekey.c file in the
> > v33-0001-Unique-key.patch.
>
> Oh, you're right, thanks. Here is the corrected patch.
I was just wondering how the distinct will work with the "skip scan"
if we have some filter? I mean every time we select the unique row
based on the prefix key and that might get rejected by an external
filter right? So I tried an example to check this.
postgres[50006]=# \d t
Table "public.t"
Column | Type | Collation | Nullable | Default
--------+---------+-----------+----------+---------
a | integer | | |
b | integer | | |
Indexes:
"idx" btree (a, b)
postgres[50006]=# insert into t select 2, i from generate_series(1, 200)i;
INSERT 0 200
postgres[50006]=# insert into t select 1, i from generate_series(1, 200)i;
INSERT 0 200
postgres[50006]=# set enable_indexskipscan =off;
SET
postgres[50006]=# select distinct(a) from t where b%100=0;
a
---
1
2
(2 rows)
postgres[50006]=# set enable_indexskipscan =on;
SET
postgres[50006]=# select distinct(a) from t where b%100=0;
a
---
(0 rows)
postgres[50006]=# explain select distinct(a) from t where b%100=0;
QUERY PLAN
-------------------------------------------------------------------
Index Only Scan using idx on t (cost=0.15..1.55 rows=10 width=4)
Skip scan: true
Filter: ((b % 100) = 0)
(3 rows)
I think in such cases we should not select the skip scan. This should
behave like we have a filter on the non-index field.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
