| From: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Eric Jiang <eric(at)doublemap(dot)com> |
| Cc: | pgsql-performance(at)postgresql(dot)org, Eric Clark <eclark(at)doublemap(dot)com> |
| Subject: | Re: Querying with multicolumn index |
| Date: | 2016-12-10 20:34:18 |
| Message-ID: | b92cec0d-c4b2-5e44-a6b9-949d2b93e935@2ndquadrant.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Hi,
On 12/10/2016 12:51 AM, Tom Lane wrote:
> Eric Jiang <eric(at)doublemap(dot)com> writes:
>> I have a query that I *think* should use a multicolumn index, but
>> sometimes isn't, resulting in slow queries.
>
> 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.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2016-12-11 00:49:23 | Re: Querying with multicolumn index |
| Previous Message | Eric Jiang | 2016-12-10 20:15:35 | Re: Querying with multicolumn index |