Re: Why is this query touching 4gb of buffers? - Mailing list pgsql-general

From hubert depesz lubaczewski
Subject Re: Why is this query touching 4gb of buffers?
Date
Msg-id aPt3bONUNkgloyrf@depesz.com
Whole thread Raw
In response to Re: Why is this query touching 4gb of buffers?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Why is this query touching 4gb of buffers?
List pgsql-general
On Fri, Oct 24, 2025 at 08:54:06AM -0400, Tom Lane wrote:
> hubert depesz lubaczewski <depesz@depesz.com> writes:
> > First run of the query generated:
> > ...
> >    ->  Index Scan using index_some_table_pending on some_table  (cost=0.42..178322.57 rows=611988 width=16) (actual
time=27962.567..27962.567rows=0 loops=1)
 
> >          Index Cond: (send_at <= '2025-10-23 12:35:48'::timestamp without time zone)
> >          Buffers: shared hit=4624 read=117838 dirtied=486
> 
> > Then, immediately I reran it, without reindex, without analyze, without anything. And I got:
> 
> >    ->  Index Scan using index_some_table_pending on some_table  (cost=0.42..178328.27 rows=612009 width=16) (actual
time=0.438..0.438rows=0 loops=1)
 
> >          Index Cond: (send_at <= '2025-10-23 12:35:48'::timestamp without time zone)
> >          Buffers: shared hit=424
> 
> > Time is irrelevant, the point is that we are going down from ~120k buffers
> > "touched" to 424 buffers. What is going on?
> 
> The first execution probably had to set hint bits on a whole lot
> of recently-deleted rows.

But why it doesn't happen/help on secondary?

Subsequent runs on secondary still have to "touch" hundreds of thousands
of pages", even if I'll do the run on primary that would reset hint
bits.

So, on primary - reruning the query fixes the "how many pages we touch"
- but on secondary, the number generally doesn't change, at least
withint 15-20 minute window.

Best regards,

depesz




pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: Why is this query touching 4gb of buffers?
Next
From: Greg Sabino Mullane
Date:
Subject: Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)