| From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
|---|---|
| To: | "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> |
| Cc: | Magnus Hagander <magnus(at)hagander(dot)net>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows |
| Date: | 2016-11-21 02:08:50 |
| Message-ID: | CAA4eK1JHysKycLWVFK348ptTJTk90sMJ=jDBqqzDxi8XnjK99A@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, Nov 21, 2016 at 5:22 AM, Tsunakawa, Takayuki
<tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com> wrote:
> From: Tsunakawa, Takayuki/綱川 貴之
>> Thank you, I'll try the read-write test with these settings on the weekend,
>> when my PC is available. I understood that your intention is to avoid being
>> affected by checkpointing and WAL segment creation.
>
> The result looks nice as follows. I took the mean value of three runs.
>
> shared_buffers tps
> 256MB 990
> 512MB 813
> 1GB 1189
> 2GB 2258
> 4GB 5003
> 8GB 5062
>
> "512MB is the largest effective size" seems to be a superstition, although I don't know the reason for the drop at 512MB.
>
It is difficult to say why the performance drops at 512MB, it could be
run-to-run variation. How long have you run each test?
--
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tsunakawa, Takayuki | 2016-11-21 02:16:06 | Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows |
| Previous Message | Tsunakawa, Takayuki | 2016-11-21 01:48:19 | Re: Patch: Implement failover on libpq connect level. |