Re: index problems (again)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Geoff Winkless <pgsqladmin(at)geoff(dot)dj>
Cc: Postgres General <pgsql-general(at)postgresql(dot)org>, Victor Yegorov <vyegorov(at)gmail(dot)com>
Subject: Re: index problems (again)
Date: 2016-03-07 14:51:45
Message-ID: 17343.1457362305@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Geoff Winkless <pgsqladmin(at)geoff(dot)dj> writes:
> So it seems that it should in fact be usable after all. So I'm still
> stumped as to why the (scdate,sc_id) index isn't used :(

Because the other way is estimated to be cheaper. The estimate is
wrong, because it's based on a statistical assumption that's wrong
(ie that sc_id and scdate are uncorrelated), but it's what we have
to work with at the moment.

As you found upthread, that index could be used in the way you want
if you had an equality condition on scdate. So the workaround
I'd suggest is to whack the query into that shape. Something
along the lines of (untested)

select min((select min(sc_id) from legs where scdate = gs))
from generate_series(20160219, 20160221) gs

This would only work well for relatively small ranges of scdate,
but if you had a large range then I think the original plan
would've been fine.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steven Xu 2016-03-07 15:30:49 Re: Custom column ordering
Previous Message Geoff Winkless 2016-03-07 14:47:13 Re: index problems (again)