Re: Scaling shared buffer eviction
От | Kevin Grittner |
---|---|
Тема | Re: Scaling shared buffer eviction |
Дата | |
Msg-id | 1409840062.55751.YahooMailNeo@web122301.mail.ne1.yahoo.com обсуждение исходный текст |
Ответ на | Re: Scaling shared buffer eviction (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> wrote: > On Thu, Sep 4, 2014 at 7:25 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> Its not difficult to handle such cases, but it can have downside also >> for the cases where demand from backends is not high. >> Consider in above case if instead of 500 more allocations, it just >> does 5 more allocations, then bgreclaimer will again have to go through >> the list and move 5 buffers and same can happen again by the time >> it moves 5 buffers. > > That's exactly the scenario in which we *want* the looping behavior. > If that's happening, then it means it's taking us exactly as long to > find 5 buffers as it takes the rest of the system to use 5 buffers. > We need to run continuously to keep up. That's what I was thinking, as long as there isn't a lot of overhead to starting and finishing a cycle. If there is, my inclination would be to try to fix that rather than to sleep and hope things don't get out of hand before it wakes up again. -- Kevin Grittner EDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: