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 <haramrae@xxxxxxxxx>:
Did you run ANALYZE on your tables before the test?
--
On 4 December 2017 at 16:01, Tomas Vondra <tomas.vondra@xxxxxxxxxxxxxxx> 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.
