On Mon, Nov 5, 2018 at 03:23:03PM +0300, Nikolay Samokhvalov wrote:
>
>
> On Mon, Nov 5, 2018 at 3:01 PM Bruce Momjian <bruce@momjian.us> wrote:
>
> > > {"effective_cache_size", PGC_USERSET, QUERY_TUNING_COST,
> > > - gettext_noop("Sets the planner's assumption about
> the size of the disk cache."),
> > > - gettext_noop("That is, the portion of the kernel's
> disk cache that "
> > > - "will be used for
> PostgreSQL data files. This is measured in disk "
> > > - "pages, which are normally
> 8 kB each."),
> > > + gettext_noop("Sets the planner's assumption about
> the size of the data cache."),
> > > + gettext_noop("That is, the size of the cache used
> for PostgreSQL data files. "
> > > + "This is measured in disk
> pages, which are normally 8 kB each."),
>
> ...
>
> Well, the change as outlined in the email is that effective_cache_size
> is a combination of shared_buffers and kernel cache size, which I think
> the docs now make clear. Do you have better wording for the GUC?
>
>
> Maybe it's better to use this phrase, "a combination of shared_buffers and
> kernel cache size"?
> Or: "a combination of shared_buffers and estimated kernel cache size".
Well, here are the lines in guc.c:
gettext_noop("Sets the planner's assumption about the size of the data cache."),
gettext_noop("That is, the size of the cache used for PostgreSQL data files. "
"This is measured in disk pages, which are normally 8 kB each."),
The first line is already on the long side compared to other entries, as
is the second gettext_noop(). How long can we make it without being too
long? Is this really the place to explain this distinction? I thought
about these issues when I wrote this patch? You can come to a different
conclusion, but please consider these issues.
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +