Re: RFC: Improve CPU cache locality of syscache searches

From: Andres Freund <andres(at)anarazel(dot)de>
To: Yura Sokolov <y(dot)sokolov(at)postgrespro(dot)ru>
Cc: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: RFC: Improve CPU cache locality of syscache searches
Date: 2021-08-06 03:49:45
Message-ID: 20210806034945.fbfrcqtjffzfuo7b@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On 2021-08-06 06:43:55 +0300, Yura Sokolov wrote:
> Why don't use simplehash or something like that? Open-addressing schemes
> show superior cache locality.

I thought about that as well - but it doesn't really resolve the question of
what we want to store in-line in the hashtable and what not. We can't store
the tuples themselves in the hashtable for a myriad of reasons (need pointer
stability, they're variably sized, way too large to move around frequently).

> Well, simplehash entry will be 24 bytes this way. If simplehash template
> supports external key/element storage, then it could be shrunk to 16 bytes,
> and syscache entries will not need dlist_node. (But it doesn't at the
> moment).

I think storing keys outside of the hashtable entry defeats the purpose of the
open addressing, given that they are always checked and that our conflict
ratio should be fairly low.

Greetings,

Andres Freund

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Noah Misch 2021-08-06 04:12:48 Re: Commitfest overflow
Previous Message Yura Sokolov 2021-08-06 03:43:55 Re: RFC: Improve CPU cache locality of syscache searches