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 
> overhead.
> 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 
> test).
> 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


Andres Freund

Reply via email to