On Tue, 3 Feb 2026 at 11:54, Radim Marek <[email protected]> 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 protected]'::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 protected]'::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 operation but the pattern is the same: > first execution incurs catalog reads that get cached for subsequent runs. > This applies to 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
