From: | Thomas Munro <munro(at)ip9(dot)org> |
---|---|
To: | Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: DISTINCT with btree skip scan |
Date: | 2014-07-05 23:24:43 |
Message-ID: | CADLWmXViay1au8duZOBzmfc_ZOOjXtNeGz1TGSUjX53oA2ehVA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 5 July 2014 02:03, Vik Fearing <vik(dot)fearing(at)dalibo(dot)com> wrote:
> [1] http://wiki.postgresql.org/wiki/Loose_indexscan
Thanks. It talks about DISTINCT, and also about using index when you
don't have the leading column in your WHERE clause (as well as MySQL
("loose"), at least Oracle ("skip"), SQLite ("skip"), DB2 ("jump") can
do this). It looks like at least MySQL can also use loose index scans
to implement GROUP BY in certain cases involving MIN or MAX aggregate
functions (things like SELECT a, MIN(b) FROM foo GROUP BY a, given an
index on (a, b)).
But I'm only trying to implement the lowest hanging index skipping
plan: plain old DISTINCT. I think I see roughly how to cost, plan and
execute it... now to learn a lot more about PG internals...
From | Date | Subject | |
---|---|---|---|
Next Message | Stephen Frost | 2014-07-06 04:47:47 | Re: tweaking NTUP_PER_BUCKET |
Previous Message | David Rowley | 2014-07-05 21:16:25 | Re: Allowing join removals for more join types |