On Wed, Aug 28, 2024 at 1:00 AM Alexander Lakhin <exclusion@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?
