Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows

From: "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>
To: 'amul sul' <sulamul(at)gmail(dot)com>
Cc: "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-07 05:16:03
Message-ID: 0A3221C70F24FB45833433255569204D1F63BF86@G01JPEXMBYT05
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

From: amul sul [mailto:sulamul(at)gmail(dot)com]
> IMHO, I think we could remove third paragraph completely and generalised
> starting of second paragraph, somewhat looks likes as
> follow:
>
> <para>
> - If you have a dedicated database server with 1GB or more of RAM,
> a
> - reasonable starting value for <varname>shared_buffers</varname>
> is 25%
> - of the memory in your system. There are some workloads where even
> + A reasonable starting value for
> <varname>shared_buffers</varname> is 25%
> + of the RAM in your system. There are some workloads where even
> large settings for <varname>shared_buffers</varname> are
> effective, but
> because <productname>PostgreSQL</productname> also relies on the
> operating system cache, it is unlikely that an allocation of more
> than

The third paragraph may be redundant, I'm a bit inclined to leave it for kindness and completeness. The attached revised patch just correct the existing typo (large -> larger).

I'll change the status to needs review.

Regards
Takayuki Tsunakawa

Attachment Content-Type Size
win_shrdbuf_perf_v2.patch application/octet-stream 1.4 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message amul sul 2016-11-07 05:43:15 Re: Remove the comment on the countereffectiveness of large shared_buffers on Windows
Previous Message Tsunakawa, Takayuki 2016-11-07 04:44:58 Re: [RFC] Should we fix postmaster to avoid slow shutdown?