Re: RFC: Improve CPU cache locality of syscache searches

From: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: RFC: Improve CPU cache locality of syscache searches
Date: 2021-08-19 23:10:37
Message-ID: CAFBsxsEj=9Og1-w81u2zRhh-eJTPLE-N83eDvbcSUF-SqocFgQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Aug 5, 2021 at 4:12 PM Andres Freund <andres(at)anarazel(dot)de> wrote:
> I have wondered before whether we should have syscache definitions
generate
> code specific to each syscache definition. I do think that'd give a good
bit
> of performance boost. But I don't see a trivial way to get there without
> notational overhead.

I've made a small step in this direction in the attached. It uses a
template approach to generate type-specific SearchCatCache* functions, for
now only the 4-key ones. Since there's only a few of those, it's manageable
to invoke the template and change the call sites by hand. To get this to
scale up to all syscaches would require some scripting, but this much is
enough to get feedback on the approach. One possible concern in starting
down this path is that hundreds of call sites would have to be changed. (If
there's a good way around that, it hasn't occurred to me.) It might also be
possible to replace the per-key invocations with a single memcpy() for most
types, but that's a bit more work.

--
John Naylor
EDB: http://www.enterprisedb.com

Attachment Content-Type Size
v1-0001-Specialize-SearchSysCache4-by-the-search-key-data.patch application/octet-stream 14.9 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2021-08-19 23:46:27 Re: elog.c query_id support vs shutdown
Previous Message David G. Johnston 2021-08-19 22:58:57 Re: [PATCH] Proof of concept for GUC improvements