Andres Freund wrote on 2018-03-02:
> 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.
You're right about 1.5 already existing. I wasn't sure about the versioning
policy for extensions and seeing as version 1.5 only 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 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.
Yes, but I wouldn't give a warranty that it is neither more nor less overhead
than 7%, seeing as for my testing, the tps were 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
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 EVO SSD ist -comparatively speaking-
Do you have any recommendations as to what constitutes adequate testing times