Re: Why is this query touching 4gb of buffers?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: depesz(at)depesz(dot)com
Cc: PostgreSQL General <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: Why is this query touching 4gb of buffers?
Date: 2025-10-24 12:54:06
Message-ID: 1754333.1761310446@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-general

hubert depesz lubaczewski <depesz(at)depesz(dot)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.567 rows=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.438 rows=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.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message hubert depesz lubaczewski 2025-10-24 12:56:12 Re: Why is this query touching 4gb of buffers?
Previous Message Greg Sabino Mullane 2025-10-24 12:53:47 Re: Index corruption issue after migration from RHEL 7 to RHEL 9 (PostgreSQL 11 streaming replication)