From: | Geoff Winkless <pgsqladmin(at)geoff(dot)dj> |
---|---|
To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DISTINCT with btree skip scan |
Date: | 2016-11-24 10:45:44 |
Message-ID: | CAEzk6ffE-YQGjfRKq+Sm4Mq=yw5EwhmP-DOMEeAG9eSoFOU+rw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 23 November 2016 at 21:19, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
> Worth pursuing? Does amskip suck? Does anyone have better ideas,
> either for how to do the low level skip or the higher level Index Skip
> Scan, or perhaps a completely different way of looking at this?
I have no helpful suggestions with how to achieve it, but can I add a
voice of encouragement: there have been a good few occasions in the
past year (we moved from another db to PG) where the lack of skip
scans has bitten us; in that case it was using MIN() and GROUP BY,
where the grouping column was the first element in the compound index
and the aggregate column was the second: in the Other DB that sort of
query was extremely quick, not so much here.
I was also idly pondering (in one of those moments of conceited
self-delusion where I thought I might actually have enough spare time
to try to work on it myself) whether it would be possible to implement
that sort of skip with two indexes (so MIN(a) GROUP BY b with separate
indexes on (a) and (b) rather than a single index (a,b)); I never got
much further than idle musings though.
Geoff
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Langote | 2016-11-24 11:13:22 | Re: Declarative partitioning - another take |
Previous Message | Amit Langote | 2016-11-24 10:34:29 | Re: Declarative partitioning - another take |