| From: | Greg Stark <stark(at)mit(dot)edu> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, Dilyan Palauzov <dilyan(dot)palauzov(at)aegee(dot)org>, PostgreSQL Bugs <pgsql-bugs(at)postgresql(dot)org> |
| Subject: | Re: Query planner skipping index depending on DISTINCT parameter order (2) |
| Date: | 2017-09-25 10:43:49 |
| Message-ID: | CAM-w4HPhUKkB6uA5vSOxZRUenACj-qAbSrcEBdmB1x1PyJ7hYA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On 17 September 2017 at 18:15, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> For plain DISTINCT, yeah we could consider other orderings ... but
> we're rather unlikely to find an index that matches all the output
> columns, regardless of what order they're in. So it's just not that
> exciting.
I don't follow this part. Are you saying a simple "select distinct a,b
from table" is unlikely to find a matching index on <b,a>? Don't we
already do exactly this for "select a,b from table group by a,b"? I
would have expected the two equivalent SQL statements to use exactly
the same infrastructure and thought it was only a matter of historical
legacy that they didn't.
--
greg
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2017-09-25 14:14:37 | Re: BUG #14825: enum type: unsafe use? |
| Previous Message | hvisage | 2017-09-25 08:45:22 | BUG #14827: "ALTER TABLE... IF NOT EXISTS...ADD.. BIGSERIAL" leaves extra sequences |