Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c)

From: Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>
To: Bryan Green <dbryan(dot)green(at)gmail(dot)com>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c)
Date: 2026-03-09 16:25:20
Message-ID: CAEudQAptRymgvmd5hQb2mk-Ft89XcSo_xvC74kv4JBA9v=D4Sg@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em seg., 9 de mar. de 2026 às 11:47, Bryan Green <dbryan(dot)green(at)gmail(dot)com>
escreveu:

> I created an example that is a little bit closer to the actual code and
> changed the compiler from C++ to C.
>
> It is interesting the optimization that the compiler has chosen for
> version 1 versus version 2. One calls
> memcpy and one doesn't. There is a good chance the inlining of memcpy as
> SSE+scalar per iteration
> will be faster for syscache scans-- which I believe are usually small (1-4
> keys?).
>
I doubt the inline version is better.
Clang is supported too and the code generated is much better with memcpy
one call outside of the loop.

>
> Probably the only reason to do this patch would be if N is normally large
> or if this is considered an
> improvement in code clarity without a detrimental impact on small N
> syscache scans.
> I realize you only said "possible small optimization". It might be
> worthwhile to benchmark the code for
> different values of n to determine if there is a tipping point either way?
>
In your opinion, shouldn't this be considered an optimization, even a
small one?

best regards,
Ranier Vilela

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2026-03-09 16:38:47 Re: Refactor handling of "-only" options in pg_dump, pg_restore
Previous Message Ahmed Et-tanany 2026-03-09 16:09:13 Re: [PATCH] Add max_logical_replication_slots GUC