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
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) |