Re: hint bit cache v6

Поиск
Список
Период
Сортировка
От Jim Nasby
Тема Re: hint bit cache v6
Дата
Msg-id E04B302F-6ED3-4907-A250-F7E5D5821266@nasby.net
обсуждение исходный текст
Ответ на Re: hint bit cache v6  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: hint bit cache v6  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Jun 29, 2011, at 3:18 PM, Robert Haas wrote:
> To be clear, I don't really think it matters how sensitive the cache
> is to a *complete* flush.  The question I want to ask is: how much
> does it take to knock ONE page out of cache?  And what are the chances
> of that happening too frequently?  It seems to me that if a run of 100
> tuples with the same previously-unseen XID is enough to knock over the
> applecart, then that's not a real high bar - you could easily hit that
> limit on a single page.  And if that isn't enough, then I don't
> understand the algorithm.

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. 
--
Jim C. Nasby, Database Architect                   jim@nasby.net
512.569.9461 (cell)                         http://jim.nasby.net




В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jeff Janes
Дата:
Сообщение: Re: pgbench--new transaction type
Следующее
От: Greg Smith
Дата:
Сообщение: Re: pgbench--new transaction type