Added to TODO:
* Consider wither increasing BM_MAX_USAGE_COUNT improves performance http://archives.postgresql.org/pgsql-hackers/2007-06/msg01007.php --------------------------------------------------------------------------- Gregory Stark wrote: > > "Tom Lane" <[EMAIL PROTECTED]> writes: > > > I don't really see why it's "overkill". > > Well I think it may be overkill in that we'll be writing out buffers that > still have a decent chance of being hit again. Effectively what we'll be doing > in the approximated LRU queue is writing out any buffer that reaches the 80% > point down the list. Even if it later gets hit and pulled up to the head > again. > > I suppose that's not wrong though, the whole idea of the clock sweep is that > that's precisely the level of precision to which it makes sense to approximate > the LRU. Ie, that any point in the top 20% is equivalent to any other and when > we use a buffer we want to promote it to somewhere "near" the head but any > point in the top 20% is good enough. Then any point in the last 20% should be > effectively "good enough" too be considered a target buffer to clean as well. > > If we find it's overkill then what we should consider doing is raising > BM_MAX_USAGE_COUNT. That's effectively tuning the percentage of the lru chain > that we decide we try to keep clean. > > -- > Gregory Stark > EnterpriseDB http://www.enterprisedb.com > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Have you searched our list archives? > > http://archives.postgresql.org -- Bruce Momjian <[EMAIL PROTECTED]> http://momjian.us EnterpriseDB http://postgres.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
