From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Eric Jiang <eric(at)doublemap(dot)com>, pgsql-performance(at)postgresql(dot)org, Eric Clark <eclark(at)doublemap(dot)com> |
Subject: | Re: Querying with multicolumn index |
Date: | 2016-12-11 00:51:33 |
Message-ID: | 14793.1481417493@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> writes:
> On 12/10/2016 12:51 AM, Tom Lane wrote:
>> I tried to duplicate this behavior, without success. Are you running
>> with nondefault planner parameters?
> My guess is this is a case of LIMIT the matching rows are uniformly
> distributed in the input data. The planner likely concludes that for a
> driver with a lot of data we'll find the first row using ix_updates_time
> very quickly, and that it will be cheaper than inspecting the larger
> multi-column index. But imagine a driver with a lots of data long time
> ago. That breaks the LIMIT fairly quickly.
The fact that it's slow enough to be a problem is doubtless related to
that effect. But AFAICS, the planner should never prefer that index
for this query, because even with a uniform-density assumption, the
index that really matches the query ought to look better.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Eric Jiang | 2016-12-11 02:08:48 | Re: Querying with multicolumn index |
Previous Message | Tom Lane | 2016-12-11 00:49:23 | Re: Querying with multicolumn index |