Re: Rethinking MemoryContext creation

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Peter Geoghegan <pg(at)bowt(dot)ie>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Rethinking MemoryContext creation
Date: 2017-12-11 17:59:32
Message-ID: c0ecca0f-f8d3-211e-e044-2e5819a28d51@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


On 12/10/2017 04:42 PM, Tom Lane wrote:
> Peter Geoghegan <pg(at)bowt(dot)ie> writes:
>> On Sat, Dec 9, 2017 at 5:53 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Overall I'm seeing about a 5% improvement in a "pgbench -S" scenario,
>>> although that number is a bit shaky since the run-to-run variation
>>> is a few percent anyway.
>
>> Is that with "-M prepared", too?
>
> No, I didn't use that.
>

FWIW I've done some measurements, and while there is a improvement, it's
far from 5%.

pgbench -S -c 1 -T 60

master patched
-----------------
18244 18534
18369 18587
18310 18479
18346 18515
18344 18557

pgbench -S -M prepared -c 1 -T 60

master patched
-----------------
35191 35231
35115 35555
35164 35686
35110 35724
35053 35762

So that's about 1.3% and 1.2% improvement. It seems fairly consistent,
but it might easily be due to different in layout of the binaries.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2017-12-11 18:06:14 Re: [HACKERS] Custom compression methods
Previous Message Robert Haas 2017-12-11 17:57:43 Re: [HACKERS] parallel.c oblivion of worker-startup failures