Another workaround could be :
explain analyze select min(risk_id),max(risk_id) from (select * from risk
where time>='2020-01-20 15:00:07+00' and time < '2020-01-21 15:00:08+00')
t;
in order to force the planner to use first the timestamp index.
However, I agree with you; we meet a planner bad be
On Wed, 24 Mar 2021 at 00:07, Rick Otten wrote:
>
>> Yes, the columns are highly correlated, but that alone doesn't seem like
>> it should be sufficient criteria to choose this plan.
>> Ie the selection criteria (1 day of data about a year ago) has a year+
>> worth of data after it and probably a
On Tue, Mar 23, 2021 at 2:52 AM Paul McGarry wrote:
>
>
> On Tue, 23 Mar 2021 at 16:13, Justin Pryzby wrote:
>
>> On Tue, Mar 23, 2021 at 03:00:38PM +1100, Paul McGarry wrote:
>> > I have a query where Postgresql (11.9 at the moment) is making an odd
>> plan
>> > choice, choosing to use index sc
On Tue, 23 Mar 2021 at 16:13, Justin Pryzby wrote:
> On Tue, Mar 23, 2021 at 03:00:38PM +1100, Paul McGarry wrote:
> > I have a query where Postgresql (11.9 at the moment) is making an odd
> plan
> > choice, choosing to use index scans which require filtering out millions
> of
> > rows, rather th
On Tue, Mar 23, 2021 at 03:00:38PM +1100, Paul McGarry wrote:
> I have a query where Postgresql (11.9 at the moment) is making an odd plan
> choice, choosing to use index scans which require filtering out millions of
> rows, rather than "just" doing an aggregate over the rows the where clause
> tar
