Re: slab allocator performance issues - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: slab allocator performance issues
Date
Msg-id 5d83ac71-9054-208d-a48a-24d9d6b61f55@enterprisedb.com
Whole thread Raw
In response to Re: slab allocator performance issues  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
Responses Re: slab allocator performance issues  (Tomas Vondra <tomas.vondra@enterprisedb.com>)
List pgsql-hackers
FWIW I tried running the benchmarks again, with some minor changes in 
the extension code - most importantly, the time is counted in microsecs 
(instead of milisecs).

I suspected the rounding might have been causing some rounding errors 
(essentially not counting anything below 1ms, because it rounds to 0), 
and the results are a bit different.

On the i5-2500k machine it's an improvement across the board, while on 
the bigger Xeon e5-2620v3 machine it shows roughly the same regression 
for the "decreasing" allocation pattern.

There's another issue in the benchmarking script - the queries are meant 
to do multiple runs for each combination of parameters, but it's written 
in a way that simply runs it once and then does cross product with the 
generate_sequence(1,5). I'll look into fixing that, but judging by the 
stability of results for similar chunk sizes it won't change much.


regards

-- 
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Attachment

pgsql-hackers by date:

Previous
From: Justin Pryzby
Date:
Subject: Re: when the startup process doesn't (logging startup delays)
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] proposal for regexp_count, regexp_instr, regexp_substr and regexp_replace