Re: Execution plan does not use index

From: Peter Coppens <peter(dot)coppens(at)datylon(dot)com>
To: Michael Lewis <mlewis(at)entrata(dot)com>
Cc: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Execution plan does not use index
Date: 2020-11-10 22:23:59
Message-ID: 70D29A79-C968-4310-B4D7-3203A739F261@datylon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

>
> Curious, what is seq_page_cost and random_page_cost?

show seq_page_cost
->1

show random_page_cost
->4

> Any idea of your cache hits for indexes?

No, I am afraid not. It’s been a long time since I went that deep in the RDBMS behaviour (must have been Oracle 7.something :) )

> If they are very high and/or you have SSD or similar fast storage, then maybe random_page_cost should be 1.1-2 and not default 4 (assuming seq_page_cost is still 1). The planner will be more likely to use an index scan if the expected cost for scanning an index (random) is closer to a sequential read. Sorry if this explanation is completely superfluous and you have already configured this.

I played around with some of the settings (also with setting enable_seqscan to false). While some of the plans did no longer use a full table scan, the performance did not really work out when I tried. Tbh, I never got too deep in those plans to find out why that would be, as I am not too keen on changing these settings in the first place.

>
> It would be interesting to see explain (analyze buffers) output so we can see the actual counts for these nodes. I'm rather surprised that the query I provided didn't use the timestamp index unless the inclusion of 3 days worth of range meant that it was estimated to be too high a fraction of the table. If you just execute only the subquery, is the index used by chance?
>
Index is not used for the subquery

explain
select mv_inner.*
from measurement_value AS mv_inner
where mv_inner.timestamp > '2020-11-06'::timestamp - interval '1 day' and mv_inner.timestamp < '2020-11-07'::timestamp + interval '1 day'
offset 0

==>

Seq Scan on measurement_value mv_inner (cost=0.00..7175777.00 rows=1219616 width=1006)
Filter: (("timestamp" > '2020-11-05 00:00:00'::timestamp without time zone) AND ("timestamp" < '2020-11-08 00:00:00'::timestamp without time zone))

> Top posting (reply with all previous copied below) is discouraged on these lists. I think because it makes the archives rather messy.

Will try to remember

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Michael Lewis 2020-11-11 00:43:55 Re: Execution plan does not use index
Previous Message Michael Lewis 2020-11-10 17:54:02 Re: Execution plan does not use index