On Tue, 3 Feb 2026 at 11:54, Radim Marek <radim@boringsql.com> wrote:
> Buffers: shared hit=4
> -> Seq Scan on sort_buffer_test (cost=0.00..2.50 rows=1 width=32) (actual time=0.042..0.126 rows=1.00
loops=1)
> Filter: (lower(email) = 'email_1@example.com'::text)
> Rows Removed by Filter: 99
> Buffers: shared hit=1
>
> vs
>
> Buffers: shared hit=1
> -> Seq Scan on sort_buffer_test (cost=0.00..2.50 rows=1 width=32) (actual time=0.021..0.057 rows=1.00
loops=1)
> Filter: (lower(email) = 'email_1@example.com'::text)
> Rows Removed by Filter: 99
> Buffers: shared hit=1
> I traced the potential issue down in case of ORDER BY to pg_amop/pg_amproc lookups. The specific lookups vary by
operationbut the pattern is the same: first execution incurs catalog reads that get cached for subsequent runs. This
appliesto DISTINCT (sort, not hashed), GROUP BY, window functions, etc - which seems to isolate it to sort node.
I'm finding it hard to fathom why you think this is a bug. We have
various caches that will require accessing various catalogue tables
and probably indexes too, which will be accessed unless the cache has
already been populated. These accessing the buffers for these are
included in the buffers count in EXPLAIN.
What is it you expect to happen here? If we access buffers and don't
report them, then IMO, that's a bug.
David
