On 2018-03-02 18:07:32 +0100, Julian Markwort wrote:
> Andres Freund wrote on 2018-03-01:
> > I think the patch probably doesn't apply anymore, due to other changes
> > to pg_stat_statements since its posting. Could you refresh?
> pgss_plans_v02.patch applies cleanly to master, there were no changes to
> pg_stat_statements since the copyright updates at the beginning of January.
> (pgss_plans_v02.patch is attached to message
> 1bd396a9-4573-55ad-7ce8-fe7adffa1...@uni-muenster.de and can be found in the
> current commitfest as well.)
Yea, I misread the diff to think you added a conflicting version. Due
-DATA =3D pg_stat_statements--1.4.sql pg_stat_statements--1.4--1.5.sql \
+DATA =3D pg_stat_statements--1.5.sql pg_stat_statements--1.4--1.5.sql \
and I'd checked that 1.5 already exists. But you just renamed the file,
presumably because it's essentially rewriting the whole file? I'm not
sure I'm a big fan of doing so, because that makes testing the upgrade
path more work.
> I've tried to gather some meaningful results, however either my testing
> methodology was flawed (as variance between all my passes of pgbench was
> rather high) or the takeaway is that the feature only generates little
> This is what I've run on my workstation using a Ryzen 1700 and 16GB of RAM
> and an old Samsung 840 Evo as boot drive, which also held the database:
> The database used for the tests was dropped and pgbench initialized anew for
> each test (pgss off, pgss on, pgss on with plan collection) using a scaling
> of 16437704*0.003~=50 (roughly what the phoronix test suite uses for a buffer
> Also similar to the phoronix test suite, I used 8 jobs and 32 connections for
> a normal multithreaded load.
> I then ran 10 passes, each for 60 seconds, with a 30 second pause between
> them, as well as another test which ran for 10 minutes.
What workload did you run? read/write or readonly? This seems like a
feature were readonly makes a lot more sense. But ~1800 tps strongly
suggests that's not what you did?
> With pg_stat_statements on, the latter test (10 minutes) resulted in 1833
> tps, while the patched version resulted in 1700 tps, so a little over 7%
> overhead? Well, the "control run", without pg_stat_statements delivered only
> 1806 tps, so variance seems to be quite high.
That's quite some overhead, I'd say.
> If anybody has any recommendations for a setup that generates less variance,
> I'll try this again.
I'd suggest disabling turboost, in my experience that makes tests
painful to repeat, because it'll strongly depend on the current HW