On Wed, Aug 28, 2024 at 1:00 AM Alexander Lakhin <exclus...@gmail.com> wrote: > gives me unstable numbers on unpatched master: > Buffers: shared hit=226 > Buffers: shared hit=217
> Buffers: shared hit=162 > Buffers: shared hit=281 > Buffers: shared hit=210 > Buffers: shared hit=233 > and also with the patch applied: > Buffers: shared hit=246 > Buffers: shared hit=197 > Buffers: shared hit=247 > Buffers: shared hit=196 > Buffers: shared hit=224 > Buffers: shared hit=219 > Buffers: shared hit=291 > Buffers: shared hit=152 > > Please correct me, if I'm doing something wrong. Huh. I can reproduce what I showed with pretty low variance, on my FreeBSD, Linux and macOS systems. I included parallel_leader_participation=off so that the workers would hopefully start as closely together in time as possible, and hopefully allow only a block or so of variation in the outcome. If I do: create or replace function f(i int) returns int language plpgsql parallel safe as $$ begin raise notice '% pid %', clock_timestamp(), pg_backend_pid(); return i; end; $$; then postgres=# explain (analyze) select f(i) from t limit 1; NOTICE: 2024-08-28 16:41:32.845747+12 pid 47019 NOTICE: 2024-08-28 16:41:32.845746+12 pid 47018 shows start times differ by only a few microseconds at most, often 0. I wonder if your system is more variable at beginning execution? Maybe you're on a multi-socket system and forking/startup times vary in some way I can't see on small systems or something like that?
