No I did not run a vacuum analyze. Do you want me to try with that first?
@Tomas:
Talking abut power management, I changed the profile for tuned-adm
to latency-performance instead of balanced (that is the default)
that is increasing performances for now and they are similar to centos 6.9.
Time: 2.121 ms
Time: 2.026 ms
Time: 1.664 ms
Time: 1.749 ms
Time: 1.656 ms
Time: 1.675 ms
Do you think this can be easily done in production as well?
2017-12-04 16:37 GMT+01:00 Alban Hertroys :
> Did you run ANALYZE on your tables before the test?
>
> On 4 December 2017 at 16:01, Tomas Vondra
> wrote:
> >
> > On 12/04/2017 02:19 PM, Nicola Contu wrote:
> > ...>
> >> centos 7 :
> >>
> >> dbname=# \timing Timing is on. cmdv3=# SELECT id FROM
> >> client_billing_account WHERE name = 'name'; id ------- ***** (1 row)
> >> Time: 3.884 ms
> >>
> >> centos 6.9
> >>
> >> dbname=# SELECT id FROM client_billing_account WHERE name = 'name'; id
> >> ------- ***** (1 row) Time: 1.620 ms
> >>
> >
> > We need to see EXPLAIN (ANALYZE,BUFFERS) for the queries.
> >
> > Are those VMs or bare metal? What CPUs and RAM are there? Have you
> > checked that power management is disabled / cpufreq uses the same
> > policy? That typically affects short CPU-bound queries.
> >
> > Other than that, I recommend performing basic system benchmarks (CPU,
> > memory, ...) and only if those machines perform equally should you look
> > for issues in PostgreSQL. Chances are the root cause is in hw or OS, in
> > which case you need to address that first.
> >
> > regards
> >
> > --
> > Tomas Vondra http://www.2ndQuadrant.com
> > PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
> >
>
>
>
> --
> If you can't see the forest for the trees,
> Cut the trees and you'll see there is no forest.
>
