From: Tom Lane <tgl@sss.pgh.pa.us>
To: Tomas Vondra <tomas.vondra@2ndquadrant.com>
cc: Eric Jiang <eric@doublemap.com>, pgsql-performance@postgresql.org,
        Eric Clark <eclark@doublemap.com>
Subject: Re: Querying with multicolumn index
In-reply-to: <b92cec0d-c4b2-5e44-a6b9-949d2b93e935@2ndquadrant.com>
References: 
 <CAOfJSTwzQ7Fx6Yjeg9mFkMsM5OVKPoa=EgkHceGdkr1TWg8vkA@mail.gmail.com>
 <5353.1481327501@sss.pgh.pa.us>
 <b92cec0d-c4b2-5e44-a6b9-949d2b93e935@2ndquadrant.com>
Comments: In-reply-to Tomas Vondra <tomas.vondra@2ndquadrant.com>
	message dated "Sat, 10 Dec 2016 21:34:18 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <14792.1481417493.1@sss.pgh.pa.us>
Date: Sat, 10 Dec 2016 19:51:33 -0500
Message-ID: <14793.1481417493@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Tomas Vondra <tomas.vondra@2ndquadrant.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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance