| От | Heikki Linnakangas |
|---|---|
| Тема | Re: Scaling shared buffer eviction |
| Дата | |
| Msg-id | 54255666.4080101@vmware.com обсуждение исходный текст |
| Ответ на | Re: Scaling shared buffer eviction (Andres Freund <andres@2ndquadrant.com>) |
| Ответы |
Re: Scaling shared buffer eviction
|
| Список | pgsql-hackers |
On 09/25/2014 05:40 PM, Andres Freund wrote: > There's two reasons for that: a) dynahash just isn't very good and it > does a lot of things that will never be necessary for these hashes. b) > the key into the hash table is*far* too wide. A significant portion of > the time is spent comparing buffer/lock tags. Hmm. Is it the comparing, or calculating the hash? We could precalculate the hash for RelFileNode+ForkNumber, and store it RelationData. At a lookup, you'd only need to mix in the block number. - Heikki
В списке pgsql-hackers по дате отправления:
Сайт использует файлы cookie для корректной работы и повышения удобства. Нажимая кнопку «Принять» или продолжая пользоваться сайтом, вы соглашаетесь на их использование в соответствии с Политикой в отношении обработки cookie ООО «ППГ», в том числе на передачу данных из файлов cookie сторонним статистическим и рекламным службам. Вы можете управлять настройками cookie через параметры вашего браузера