On Mon, Nov 5, 2018 at 03:23:03PM +0300, Nikolay Samokhvalov wrote: > > > On Mon, Nov 5, 2018 at 3:01 PM Bruce Momjian <br...@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 <br...@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 +