Re: Incorrect result of bitmap heap scan.

From: "Core Studios Inc(dot)" <corestudiosinc(at)gmail(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>, Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>, Peter Geoghegan <pg(at)bowt(dot)ie>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>, Melanie Plageman <melanieplageman(at)gmail(dot)com>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, Konstantin Knizhnik <knizhnik(at)garret(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alexander Kuzmenkov <akuzmenkov(at)timescale(dot)com>
Subject: Re: Incorrect result of bitmap heap scan.
Date: 2025-09-16 12:47:08
Message-ID: 6def0a24-fc55-44fe-8e58-bab6addd4615@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

We could not pin this down to a specific query, but here's one frequent
query that is running on the said table:

piers=> EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM events
WHERE priority = 'high' and ( events.fire_at <= now()  +
interval '1 hour' ) AND ( events.fire_at >= now() )
ORDER BY fire_at ASC
LIMIT 1000;
QUERY PLAN
--------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=2.80..2.81 rows=1 width=453) (actual
time=0.598..0.618 rows=222 loops=1)
   Buffers: shared hit=224
   ->  Sort  (cost=2.80..2.81 rows=1 width=453) (actual
time=0.598..0.606 rows=222 loops=1)
         Sort Key: fire_at
         Sort Method: quicksort  Memory: 241kB
         Buffers: shared hit=224
         ->  Bitmap Heap Scan on events  (cost=1.67..2.79
rows=1 width=453) (actual time=0.073..0.465 rows=222 loops=1)
               Recheck Cond: (((priority)::text = 'high'::text)
AND (fire_at <= (now() + '01:00:00'::interval)) AND (fire_at >=
now()))
               Heap Blocks: exact=219
               Buffers: shared hit=224
               ->  Bitmap Index Scan on
index_events_on_priority_fire_at  (cost=0.00..1.67 rows=1
width=0) (actual time=0.052..0.052 rows=222 loops=1)
                     Index Cond: (((queue)::text =
'high'::text) AND (fire_at <= (now() + '01:00:00'::interval))
AND (fire_at >= now()))
                     Buffers: shared hit=5
 Planning Time: 0.067 ms
 Execution Time: 0.646 ms
(15 rows)

Interestingly, before the upgrade we see that the majority of query
plans for this query are not executing any Bitmap Heap Scans:

---------------------------------------------------------------------------------------------------------------------------------------------------------
 Limit  (cost=0.56..2.78 rows=1 width=468) (actual
time=0.028..0.489 rows=217 loops=1)
   Buffers: shared hit=222
   ->  Index Scan using index_events_on_priority_fire_at on
events  (cost=0.56..2.78 rows=1 width=468) (actual
time=0.027..0.473 rows=217 loops=1)
         Index Cond: (((priority)::text = 'high'::text) AND
(fire_at <= (now() + '01:00:00'::interval)) AND (fire_at >= now()))
         Buffers: shared hit=222
 Planning:
   Buffers: shared hit=64
 Planning Time: 0.312 ms
 Execution Time: 0.512 ms
(9 rows)

Thanks in advance

On 9/16/25 3:25 PM, Andres Freund wrote:
> Hi,
>
> On September 16, 2025 7:57:54 AM EDT, "Core Studios Inc."<corestudiosinc(at)gmail(dot)com> wrote:
>> Hello,
>>
>> We noticed a sustained increased in IO Wait of read queries after upgrading from 13.13 to 13.21. Eventually, we narrowed it down to a spike in index_blocks_read of a certain table where Bitmap Heap Scans do happen.
>>
>> Do you think that this change (i.e. removing the optimization) could be what caused this regression?
> You're not providing enough details for us to answer that question. We'd need an explain verbose for the query.
>
> Greetings,
>
> Andres

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2025-09-16 12:55:12 Re: Improving the names generated for indexes on expressions
Previous Message David G. Johnston 2025-09-16 12:39:21 Re: Improving the names generated for indexes on expressions