Re: hint bit cache v6
От | Robert Haas |
---|---|
Тема | Re: hint bit cache v6 |
Дата | |
Msg-id | BANLkTin0o4qroc0As1nR32QiBDSVZqs5Ug@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: hint bit cache v6 (Jim Nasby <jim@nasby.net>) |
Список | pgsql-hackers |
On Thu, Jun 30, 2011 at 12:31 AM, Jim Nasby <jim@nasby.net> wrote: > Would it be reasonable to keep a second level cache that store individual XIDs instead of blocks? That would provide protectionfor XIDs that are extremely common but don't have a good fit with the pattern of XID ranges that we're caching.I would expect this to happen if you had a transaction that touched a bunch of data (ie: bulk load or update) sometime ago (so the other XIDs around it are less likely to be interesting) but not old enough to have been frozen yet.Obviously you couldn't keep too many XIDs in this secondary cache, but if you're just trying to prevent certain pathologicalcases then hopefully you wouldn't need to keep that many. Maybe, but I think that's probably still papering around the problem. I'd really like to find an algorithm that bounds how often we can flush a page out of the cache to some number of tuples significantly greater than 100. The one I suggested yesterday has that property, for example, although it may have other problems I'm not thinking of. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: