Re: effective_cache_size

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 +