Обсуждение: effective_cache_size

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

Manfred Koizar <mkoi-pg@aon.at> writes:
> The estimator only uses effective_cache_size, it never looks at
> NBuffers.  So shouldn't we add
>     if (effective_cache_size < NBuffers)

Pretty useless considering that effective_cache_size can be SET on the
fly...

In general, my philosophy has been not to constrain settings of
optimizer cost parameters more than absolutely necessary.  For example,
the system will let you set random_page_cost to values between 0 and 1,
even though values less than 1 are surely nonsensical.  Once in a while
someone might want to do that just for testing purposes...
        regards, tom lane