> On 03/21/2018 10:26 AM, Richard Biener wrote: > >On Tue, Mar 20, 2018 at 8:57 PM, Martin Liška <mli...@suse.cz> wrote: > >>Hi. > >> > >>I did similar stats for postgresql server, more precisely for pgbench: > >>pgbench -s100 & 10 runs of pgbench -t10000 -v > > > >Without looking at the benchmark probably only because it is flawed > >(aka not I/O or memory bandwidth limited). It might have some > >actual operations on data (regex code?) that we can speed up though. > > Well, it's not ideal as it tests quite simple DB with just couple of tables: > ``` > By default, pgbench tests a scenario that is loosely based on TPC-B, > involving five SELECT, UPDATE, and INSERT commands per transaction. > ``` > > Note that I had pg_data in /dev/shm and I verified that CPU utilization was > 100% on a single core. > That said, it should not be so misleading ;)
Well, it is usually easy to do perf and look how hot spots looks like. I see similar speedups for common page lading at firefox and similar benchmarks that are quite good. Not everything needs to be designed to be memory bound like spec. Honza > > Martin > > > > >Richard. > > > >>Martin >
