effective_cache_size - Mailing list pgsql-hackers

From Manfred Koizar
Subject effective_cache_size
Date
Msg-id fhqqiukgmorla7tdcdbt690d1ms310hddj@4ax.com
Whole thread Raw
Responses Re: effective_cache_size  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
The estimator only uses effective_cache_size, it never looks at
NBuffers.  So shouldn't we addif (effective_cache_size < NBuffers){    elog(NOTICE, "adjusting effective_cache_size to
%d",                NBuffers);    effective_cache_size = NBuffers;}
 

somewhere near * Check for invalid combinations of switches

in postmaster.c?  I can see only one reason not to it:  If
effective_cache_size were meant as a hint to the backend that it
cannot count on the whole buffer cache, because it has to share the
cache with other backends;  though I didn't find any indication of
such an intention.  Am I missing something else?

In costsize.c there is this comment:
* We also use a rough estimate "effective_cache_size" of the number
of* disk pages in Postgres + OS-level disk cache.  (We can't simply use* NBuffers for this purpose because that would
ignorethe effects of* the kernel's disk cache.)
 

In the docs we have:

EFFECTIVE_CACHE_SIZE (floating point):  Sets the optimizer's
assumption about the effective size of the disk cache (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. 

What about adding something like "including the effects of the
backend's own shared buffers" here?

ServusManfred


pgsql-hackers by date:

Previous
From: "Jeff MacDonald"
Date:
Subject: Re: I am being interviewed by OReilly
Next
From: Vince Vielhaber
Date:
Subject: Re: I am being interviewed by OReilly