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 …
If you have a workload not fitting in s_b, with a cache hit ratio of say 95% and an uneven distribution of those accesses (i.e. almost all realistic ones), there'll be a lot of buffers with low usagecounts. But they still can save a *LOT* of IO.
-
-
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.
- 7 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.