On Thu, 19 Sept 2024 at 13:49, Tatsuo Ishii <ishii@postgresql.org> wrote:
> I also ran your query with count 1000.
>
> without the patch:
> Time: 3.655 ms
> Time: 4.123 ms
> Time: 2.163 ms
>
> wit the patch:
> Time: 3.641 ms
> Time: 2.356 ms
> Time: 2.347 ms
>
> It seems with the patch the performance is slightly better or almost
> same. I think the patch improves the performance without sacrificing
> the smaller iteration case.
You might need to use pgbench to get more stable results with such a
small test. If your CPU clocks down when idle, it's not going to clock
up as fast as you might like it to when you give it something to do.
Here's what I got when running 1000 iterations:
$ cat bench.sql
with recursive cte (a) as (select 1 union all select cte.a+1 from cte
where cte.a+1 <= 1000) select count(*) from cte;
master
$ for i in {1..5}; do pgbench -n -f bench.sql -T 10 -M prepared
postgres | grep latency; done
latency average = 0.251 ms
latency average = 0.254 ms
latency average = 0.251 ms
latency average = 0.252 ms
latency average = 0.253 ms
patched
$ for i in {1..5}; do pgbench -n -f bench.sql -T 10 -M prepared
postgres | grep latency; done
latency average = 0.202 ms
latency average = 0.202 ms
latency average = 0.207 ms
latency average = 0.202 ms
latency average = 0.202 ms (~24.2% faster)
David
