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
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 |