Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)

Andres Freund wrote on 2018-03-02:
> Yea, I misread the diff to think you added a conflicting version. Due
> to:
> -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.

You're right about 1.5 already existing. I wasn't sure about the versioning policy for extensions and seeing as version
1.5only changed a few grants I quasi reused 1.5 for my intentions. 

> 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?

I'm sorry I forgot to mention this; I ran all tests as read-write.

> > With pg_stat_statements on, the latter test (10 minutes) resulted in 1833 tps, while the patched version resulted
in1700 tps, so a little over 7% overhead? Well, the "control run", without pg_stat_statements delivered only 1806 tps,
sovariance seems to be quite high. 

> That's quite some overhead, I'd say.

Yes, but I wouldn't give a warranty that it is neither more nor less overhead than 7%, seeing as for my testing, the
tpswere higher for (unmodified) pgss enabled vs no pgss at all. 

> > 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
> temperature.
This might be a problem for average systems but I'm fairly certain this isn't the issue here.

I might try some more benchmarks and will in particular look into running read-only tests, as the aforementioned 840
EVOSSD ist -comparatively speaking- pretty slow. 
Do you have any recommendations as to what constitutes adequate testing times regarding pgbench?

Kind regards
Julian