Re: generic plans and "initial" pruning

From: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Daniel Gustafsson <daniel(at)yesql(dot)se>, David Rowley <dgrowleyml(at)gmail(dot)com>, Jacob Champion <jchampion(at)timescale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Thom Brown <thom(at)linux(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Subject: Re: generic plans and "initial" pruning
Date: 2024-06-19 17:09:26
Message-ID: 202406191709.jbvpf7d7hl6g@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

I had occasion to run the same benchmark you described in the initial
email in this thread. To do so I applied patch series v49 on top of
07cb29737a4e, which is just one that happened to have the same date as
v49.

I then used a script like this (against a server having
plan_cache_mode=force_generic_mode)

for numparts in 0 1 2 4 8 16 32 48 64 80 81 96 127 128 160 200 256 257 288 300 384 512 1024 1536 2048; do
pgbench testdb -i --partitions=$numparts 2>/dev/null
echo -ne "$numparts\t"
pgbench -n testdb -S -T30 -Mprepared | grep "^tps" | sed -e 's/^tps = \([0-9.]*\) .*/\1/'
done

and did the same with the commit mentioned above (that is, unpatched).
I got this table as result

partitions │ patched │ 07cb29737a
────────────┼──────────────┼──────────────
0 │ 65632.090431 │ 68967.712741
1 │ 68096.641831 │ 65356.587223
2 │ 59456.507575 │ 60884.679464
4 │ 62097.426 │ 59698.747104
8 │ 58044.311175 │ 57817.104562
16 │ 59741.926563 │ 52549.916262
32 │ 59261.693449 │ 44815.317215
48 │ 59047.125629 │ 38362.123652
64 │ 59748.738797 │ 34051.158525
80 │ 59276.839183 │ 32026.135076
81 │ 62318.572932 │ 30418.122933
96 │ 59678.857163 │ 28478.113651
127 │ 58761.960028 │ 24272.303742
128 │ 59934.268306 │ 24275.214593
160 │ 56688.790899 │ 21119.043564
200 │ 56323.188599 │ 18111.212849
256 │ 55915.22466 │ 14753.953709
257 │ 57810.530461 │ 15093.497575
288 │ 56874.780092 │ 13873.332162
300 │ 57222.056549 │ 13463.768946
384 │ 54073.77295 │ 11183.558339
512 │ 37503.766847 │ 8114.32532
1024 │ 42746.866448 │ 4468.41359
1536 │ 39500.58411 │ 3049.984599
2048 │ 36988.519486 │ 2269.362006

where already at 16 partitions we can see that things are going downhill
with the unpatched code. (However, what happens when the table is not
partitioned looks a bit funny.)

I hope we can get this new executor code in 18.

--
Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/
"La primera ley de las demostraciones en vivo es: no trate de usar el sistema.
Escriba un guión que no toque nada para no causar daños." (Jakob Nielsen)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2024-06-19 17:21:25 Re: Don't process multi xmax in FreezeMultiXactId() if it is already marked as invalid.
Previous Message Yura Sokolov 2024-06-19 17:00:28 Re: Maybe don't process multi xmax in FreezeMultiXactId() if it is already marked as invalid?