Re: Streaming read-ready sequential scan code

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?