From: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | Sergei Kornilov <sk(at)zsrv(dot)org>, legrand legrand <legrand_legrand(at)hotmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Planning counters in pg_stat_statements (using pgss_store) |
Date: | 2019-09-10 22:30:25 |
Message-ID: | CAOBaU_b-SyoQjbfkmhx5NULr88Lk1+X4k1cvRfrGwrsxEEhU_g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 6, 2019 at 4:19 PM Tomas Vondra
<tomas(dot)vondra(at)2ndquadrant(dot)com> wrote:
>
> On Wed, Sep 04, 2019 at 07:19:47PM +0300, Sergei Kornilov wrote:
> >
> > ...
> >
> >Results:
> >
> > test | mode | average_tps | degradation_perc
> >----------------------+----------+-------------+------------------
> > head_no_pgss | extended | 13816 | 1.000
> > patch_not_loaded | extended | 13755 | 0.996
> > head_track_none | extended | 13607 | 0.985
> > patch_track_none | extended | 13560 | 0.981
> > head_track_top | extended | 13277 | 0.961
> > patch_track_top | extended | 13189 | 0.955
> > patch_track_planning | extended | 12983 | 0.940
> > head_no_pgss | prepared | 29101 | 1.000
> > head_track_none | prepared | 28510 | 0.980
> > patch_track_none | prepared | 28481 | 0.979
> > patch_not_loaded | prepared | 28382 | 0.975
> > patch_track_planning | prepared | 28046 | 0.964
> > head_track_top | prepared | 28035 | 0.963
> > patch_track_top | prepared | 27973 | 0.961
> > head_no_pgss | simple | 16733 | 1.000
> > patch_not_loaded | simple | 16552 | 0.989
> > head_track_none | simple | 16452 | 0.983
> > patch_track_none | simple | 16365 | 0.978
> > head_track_top | simple | 15867 | 0.948
> > patch_track_top | simple | 15820 | 0.945
> > patch_track_planning | simple | 15739 | 0.941
> >
> >So I found slight slowdown with track_planning = off compared to HEAD. Possibly just at the level of measurement error. I think this is ok.
> >track_planning = on also has no dramatic impact. In my opinion proposed design with pgss_store call is acceptable.
> >
>
> FWIW I've done some benchmarking on this too, with a single pgbench client
> running select-only test on a tiny database, in different modes (simple,
> extended, prepared). I've done that on two systems with different CPUs
> (spreadsheet with results attached).
>
> I don't see any performance regression - there are some small variations
> in both directions (say, ~1%) but that's well within the noise. So I think
> the patch is fine in this regard.
Thanks a lot Sergei and Tomas! It's good to know that this patch
doesn't add significant overhead.
From | Date | Subject | |
---|---|---|---|
Next Message | Nikita Glukhov | 2019-09-10 22:44:28 | Re: [PATCH] Opclass parameters |
Previous Message | Tomas Vondra | 2019-09-10 22:28:12 | Re: Multivariate MCV list vs. statistics target |