Re: Query planner skipping index depending on DISTINCT parameter order (2)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
Cc: Dilyan Palauzov <dilyan(dot)palauzov(at)aegee(dot)org>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: Query planner skipping index depending on DISTINCT parameter order (2)
Date: 2017-09-17 17:15:34
Message-ID: 12044.1505668534@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> On 09/17/2017 02:30 AM, Dilyan Palauzov wrote:
>> The behaviour behind DISTINCT and indexes surprises me, as the
>> query planner does reorder the columns for SELECT to determine the
>> most suitable index.

> Well, I agree it's somewhat reasonable optimization. The thing is, the
> planner/optimizer does not start with all features on day 1, it gets
> improved over time. And no one implemented this bit yet.

For the DISTINCT ON case, the user-visible semantics are actually pretty
tightly tied to ORDER BY, so that it would not be very reasonable to
consider any other orderings than the given column order anyway.

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.

IOW, somebody might get around to this someday, but don't hold your
breath; there's lots of higher-value fruit to be reaching for.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message e.delanoe 2017-09-18 08:24:35 BUG #14818: PLPGSQL: write access to a field of an array of records (well defined)
Previous Message Tomas Vondra 2017-09-17 16:39:27 Re: Query planner skipping index depending on DISTINCT parameter order (2)