Re: Scaling shared buffer eviction
От | Heikki Linnakangas |
---|---|
Тема | Re: Scaling shared buffer eviction |
Дата | |
Msg-id | 54256E8B.7050502@vmware.com обсуждение исходный текст |
Ответ на | Re: Scaling shared buffer eviction (Andres Freund <andres@2ndquadrant.com>) |
Ответы |
Re: Scaling shared buffer eviction
|
Список | pgsql-hackers |
On 09/26/2014 03:26 PM, Andres Freund wrote: > On 2014-09-26 15:04:54 +0300, Heikki Linnakangas wrote: >> 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? > > Neither, really. The hash calculation is visible in the profile, but not > that pronounced yet. The primary thing noticeable in profiles (besides > cache efficiency) is the comparison of the full tag after locating a > possible match in a bucket. 20 byte memcmp's aren't free. Hmm. We could provide a custom compare function instead of relying on memcmp. We can do somewhat better than generic memcmo when we know that the BufferTag is MAXALIGNed (is it? at least it's 4 bytes aligned), and it's always exactly 20 bytes. I wonder if you're actually just seeing a cache miss showing up in the profile, though. - Heikki
В списке pgsql-hackers по дате отправления: