Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02) - Mailing list pgsql-hackers

From Julian Markwort
Subject Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)
Date
Msg-id permail-201803021955498218e1ae00005d58-j_mark05@message-id.uni-muenster.de
Whole thread Raw
In response to Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [HACKERS] [FEATURE PATCH] pg_stat_statements with plans (v02)
Next
From: Andres Freund
Date:
Subject: Re: 2018-03 Commitfest Summary (Andres #3)