On Mon, May 7, 2018 at 12:54 PM, Юрий Соколов <funny.fal...@gmail.com> wrote: >> Even if we have that, or something with similar effects, it's still >> desirable to avoid bumping the usage count multiple times for accesses >> that happen close together in time. I don't really agree with Yura >> Sokolov's proposal for how to prevent that problem, because during >> periods when no buffer eviction is happening it basically throws out >> all of the data: no items are replaced, and the usage count can't be >> bumped again until NBlocks/32 items are replaced. That's bad. > > That is not as bad as it seems on first glance: during period when > no buffer eviction is happenning, all information is almost irrelevant, > because it is naturally outdated. And due to choose of "batch" size (25), > there is always window between "NBlocks/32 items replaced" and > "this item is considered for replacement": even if all items in > 25/32*NBlocks had non-zero usage count, then there are at least > 7/32*NBlocks to consider before this item could be replaced, during > which usage count can be incremented.
I don't agree that the information is almost irrelevant. If we have a working set that starts out fitting within shared_buffers and then grows larger, we want to know which parts of the data were being accessed frequently just prior to the point where we started evicting things. Otherwise we basically evict at random for a while, and that's not good. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
