| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> |
| Cc: | Andres Freund <andres(at)anarazel(dot)de>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: POC: Cache data in GetSnapshotData() |
| Date: | 2017-09-20 18:15:51 |
| Message-ID: | CA+TgmoZx2Q-8Xnz9+0XvdHp9s3yq+_Yy1Ka5ERPXEcYuAeCQGg@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Aug 29, 2017 at 1:57 AM, Mithun Cy <mithun(dot)cy(at)enterprisedb(dot)com> wrote:
> All TPS are median of 3 runs
> Clients TPS-With Patch 05 TPS-Base %Diff
> 1 752.461117 755.186777 -0.3%
> 64 32171.296537 31202.153576 +3.1%
> 128 41059.660769 40061.929658 +2.49%
>
> I will do some profiling and find out why this case is not costing us
> some performance due to caching overhead.
So, this shows only a 2.49% improvement at 128 clients but in the
earlier message you reported a 39% speedup at 256 clients. Is that
really correct? There's basically no improvement up to threads = 2 x
CPU cores, and then after that it starts to improve rapidly? What
happens at intermediate points, like 160, 192, 224 clients?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Geoghegan | 2017-09-20 18:23:58 | Re: CREATE COLLATION does not sanitize ICU's BCP 47 language tags. Should it? |
| Previous Message | Andres Freund | 2017-09-20 17:52:15 | Re: JIT compiling expressions/deform + inlining prototype v2.0 |