Re: Streaming read-ready sequential scan code

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