On Wed, Sep 04, 2019 at 07:19:47PM +0300, Sergei Kornilov wrote:
...
Results:
test | mode | average_tps | degradation_perc
----------------------+----------+-------------+------------------
head_no_pgss | extended | 13816 | 1.000
patch_not_loaded | extended | 13755 | 0.996
head_track_none | extended | 13607 | 0.985
patch_track_none | extended | 13560 | 0.981
head_track_top | extended | 13277 | 0.961
patch_track_top | extended | 13189 | 0.955
patch_track_planning | extended | 12983 | 0.940
head_no_pgss | prepared | 29101 | 1.000
head_track_none | prepared | 28510 | 0.980
patch_track_none | prepared | 28481 | 0.979
patch_not_loaded | prepared | 28382 | 0.975
patch_track_planning | prepared | 28046 | 0.964
head_track_top | prepared | 28035 | 0.963
patch_track_top | prepared | 27973 | 0.961
head_no_pgss | simple | 16733 | 1.000
patch_not_loaded | simple | 16552 | 0.989
head_track_none | simple | 16452 | 0.983
patch_track_none | simple | 16365 | 0.978
head_track_top | simple | 15867 | 0.948
patch_track_top | simple | 15820 | 0.945
patch_track_planning | simple | 15739 | 0.941
So I found slight slowdown with track_planning = off compared to HEAD. Possibly
just at the level of measurement error. I think this is ok.
track_planning = on also has no dramatic impact. In my opinion proposed design
with pgss_store call is acceptable.
FWIW I've done some benchmarking on this too, with a single pgbench client
running select-only test on a tiny database, in different modes (simple,
extended, prepared). I've done that on two systems with different CPUs
(spreadsheet with results attached).
I don't see any performance regression - there are some small variations
in both directions (say, ~1%) but that's well within the noise. So I think
the patch is fine in this regard.
regards
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
