Tomas Vondra <tomas.vondra@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
