Postgres 进行昂贵的索引扫描

Question

I have a table with ~4.5 million data for 3 months. I have indexed the "accessedAt" column which stores time in epoch and has datatype BIGINT, When I ran the query postgres did a bit map index scan on 700K rows. in (~48.2s). But when I dropped the index it did a seq scan on 700K rows in (~4s).

[QUERY] explain analyze select id from access_histories where "accessedAt" >= 1631903400 and "accessedAt" <= 1633112999; ie from 17 sept 2021 - 01 oct 2021.

Bitmap Heap Scan on access_histories  (cost=14655.35..144416.85 rows=715992 width=8) (actual time=198.176..48191.067 rows=715535 loops=1)
   Recheck Cond: (("accessedAt" >= 1631903400) AND ("accessedAt" <= 1633112999))
   Rows Removed by Index Recheck: 1716759
   Heap Blocks: exact=48015 lossy=33133
   ->  Bitmap Index Scan on "access_histories_accessedAt_idx"  (cost=0.00..14476.35 rows=715992 width=0) (actual time=185.932..185.937 rows=715535 loops=1)
         Index Cond: (("accessedAt" >= 1631903400) AND ("accessedAt" <= 1633112999))
 Planning Time: 0.553 ms
 Execution Time: 48234.459 ms

After dropping the index.

 Seq Scan on access_histories  (cost=0.00..155405.02 rows=715992 width=8) (actual time=2.560..3943.902 rows=715535 loops=1)
   Filter: (("accessedAt" >= 1631903400) AND ("accessedAt" <= 1633112999))
   Rows Removed by Filter: 4234466
 Planning Time: 0.206 ms
 Execution Time: 3982.995 ms
(5 rows)

So my question is why is postgres opting to go for index scan although sequential is less expensive.

ps I know that postgres will go for seq scan if it has to query 5-10% of total data .

Answer 1

There are several things that can work together in this:

1. work_mem is too low for the bitmap heap scan to be as effective as PostgreSQL things it should be ( Heap Blocks: lossy=33133 )

2. During the second query, more data are cached (use EXPLAIN (ANALYZE, BUFFERS) to keep track of that)