It's also possible to figure out what your actual shared buffers needs are as well! #postgresql https://www.keithf4.com/a-small-database-does-not-mean-small-shared_buffers/ …https://twitter.com/AndresFreundTec/status/1178765225895399424 …
So unless you have a cache hit ratio very close to 100%, the usagecount analysis in that blog post doesn't tell whether specific shared buffers are useful or not. And in that case there's still no reason to use 3 as the cutoff (either 5 or 1 could make at least as much sense).
-
-
Pretty much by definition, as long as there some buffers need to be evicted to make room for others (i.e. workload doesn't fit into shared buffers), there will be buffers with usagecount <= 3 most of the time. The clock sweep logic *forces* that to be the case.
-
Iteratively applying the approach presented, will almost always lead to a even smaller shared buffers recommendation in each further round. With a smaller s_b setting, there necessarily needs to be buffer replacement, which in turn means there'll be buffers with usagecount < 3.
- 6 more replies
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.