| From: | lakshmi <lakshmigcdac(at)gmail(dot)com> |
|---|---|
| To: | Ranier Vilela <ranier(dot)vf(at)gmail(dot)com> |
| Cc: | Bryan Green <dbryan(dot)green(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c) |
| Date: | 2026-03-25 11:29:35 |
| Message-ID: | CAEvyyTgcuGXmMoG0bBy85crZ2TROodRoeg=b6jzQxTprGsNm1Q@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Hi,
>>
>> Thanks for the suggestion and for the earlier discussion.
>>
> Could you repeat the tests without enable-debug?
>
I repeated the tests using a non-debug (optimized) build of PostgreSQL
(19devel), built without --enable-debug.
Test setup:
-
Debian Linux (x86_64)
-
gcc 12.2.0
-
AMD Ryzen 5 7535U (6 cores / 12 threads)
-
pgbench scale factor 1
-
command: pgbench -p 55432 -d postgres -c 10 -j 4 -T 60 I ran multiple
iterations for both the original and patched versions and considered the
stable runs (excluding those affected by checkpoints).
Results:
Original:
TPS: ~1047
Latency: ~9.5 ms
Patched:
TPS: ~1040
Latency: ~9.6 ms
From these runs, the results are quite close, and I didn’t observe a
consistent performance improvement with the patch under this workload. The
differences appear to be within normal run-to-run variation.
It may be that this change has limited impact in typical cases where the
number of keys is small. It would be interesting to see how it behaves with
workloads involving larger numbers of keys or different access patterns.
Please let me know if you’d like me to try any additional scenarios.
Regards,
Lakshmi
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ranier Vilela | 2026-03-25 11:38:55 | Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c) |
| Previous Message | John Naylor | 2026-03-25 11:10:08 | Re: Lowering the default wal_blocksize to 4K |