Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5MZt-003Arz-3D for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 11:39:14 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w5MZq-00DsiR-01 for pgsql-hackers@arkaria.postgresql.org; Wed, 25 Mar 2026 11:39:10 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1w5MZp-00DsiJ-1W for pgsql-hackers@lists.postgresql.org; Wed, 25 Mar 2026 11:39:10 +0000 Received: from mail-dl1-x122b.google.com ([2607:f8b0:4864:20::122b]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w5MZo-00000000xWJ-0RKs for pgsql-hackers@postgresql.org; Wed, 25 Mar 2026 11:39:09 +0000 Received: by mail-dl1-x122b.google.com with SMTP id a92af1059eb24-128e4d0cc48so5823043c88.1 for ; Wed, 25 Mar 2026 04:39:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1774438747; cv=none; d=google.com; s=arc-20240605; b=kIoQ/0AbgNvm5DzXNyDmZIdgfQ+GaKiMNNY9MtS9IC3dpDfbdxsuc6eHWD+7Awctli TitN8h5mpPXOoFr4cTzFJJbfmorWd7VlHlcdWjBFR8Uj2FJPuKtBCqX3i8PVW0nZBlNu oxTjVe62Xz5gab6MhLPIYcTUsk+roGQ3VIFXTimk4dIa1nOQ1yALdtiKy5GcjPNgXYBB ZSIIK/Gxj1HvU+BZQhh2f5imoBvZTdtNV3AWF23b6/d8mqpeby7OWMi1uuBQh45phgGu KjCpvNaQQgoa/FYpza4X1mYi/53iJBe/AVOYdC60fnz33Ll8530rMJ7ZPMbZrrbx025M jlQA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=dYMUEl57q+Dc1WP2Zr8VxcSa74/9YyzDf7RUC4dbcRQ=; fh=aL5uhNZjq6eW1AjRgIcLWMYRNQXn867o6icW6RRsA3U=; b=I/3voqfELB+wlFvcB7+TUfhV8NfvFamEA68zhLJVaOgqvVmFdjhhAT9h0yi+Ztq/ys wsSPtR1iNBYak//di+qDUISrdNDrmkYwQoR64o8W1XSRojb9ylHZvRF9tDQjeeO+hfu3 YTZ2Oe2bPsRPZQl3yZfYFJwgSbnu/+TcfO1y+y0s3PdXHA9ToYl/l3Rg6GWjm7ChwZgk NPX/T5ZcFOT5y4uvIUuheWFfXIAd7iH/p0hI5KNMTx8EaIfxabFbadTTsbeUCYXadIh3 0rxMt7WhWozIKm8iSMDLaMVmewEjh/L++NP8GZUS3WiD/3kysc/cbP1a16oirJwq9epY kSDA==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1774438747; x=1775043547; darn=postgresql.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dYMUEl57q+Dc1WP2Zr8VxcSa74/9YyzDf7RUC4dbcRQ=; b=sNcBWiYm8JqRqcl5lgh3U9ratWG3zvoEmmdwhZY31Py0ZCmIqMDBOV1GZBcsdyIM09 J4jNc51HIM4U7W9gELmva4hKN0PMCYtiaRYexmzeKAcZO3NAmOAnfvnhjrqhQl+Nd8lc TJk3ZpCpyRtTYa6aw+o2uMdu2x/vJ5i6CpZ8d+BCPoQIAGJiMirii56cTb+GZqCRT3Np pp1ZrGVySN3fTkaBmWNoAKKesec7GiG+S+j926ASHSkhvuD2lQhJta0Y+IH0J7SPAu5c lUKMY+0HE6tzGtnea5e88hI1op1BDMTDCD1xUtCaFclbvDq/PpVo9CF/6xtFZpQLHu0p sp5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1774438747; x=1775043547; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dYMUEl57q+Dc1WP2Zr8VxcSa74/9YyzDf7RUC4dbcRQ=; b=cc00o2xWMYNv3oImMDQMvrdn78QacS+CDid3bqjRg75q1ie+tH/a1FWocK8MaBm263 0SnY48X0ehENdIAskrK8QGxWmX4V9XeVc2tKLj06crQiMkvnmlaaCL2Cbk3ZuPlZJeA8 wgvA8rMPpRD6tzPM00wjBp/bjx/j3e8nb5zWM7lSZb5aoJKZt1XNEWh27l2WJY9IzjGR XDfgREQaortYVxz7BfbMalY36uvhSIY9zUE9mXc3p4NjiG4N9bM8qA9148jGRPN6s411 yfwiqBO3Iex+YzLDtt6JYCp2QeAqCLMMioo3PU7yJv5LUZoOPjH3Lr+6PlMQR2m3FuLN 7Qcw== X-Forwarded-Encrypted: i=1; AJvYcCUVJmpjg6TABDsjF66jzBLZafsge4XFUbZz48FS37hvEzESAEwpG6K+4taenvCXmxBtDVAPQqFPfwrvABot@postgresql.org X-Gm-Message-State: AOJu0YzDkU9ocspFPn1Ij+ADIE237pcFhrglT9b34rrwhhiomXp4HK2e unqfqOsaKk3YrfUz0oxIWWquz+csmwDeSvrFLQxZ/h6G9LXYokjcxGn/4jl1m2hpHshwezHwPat M4FwgmL0tyI4eCHIACH3e6kRhALBgS3k= X-Gm-Gg: ATEYQzyyG7iSgV/lCTTs3UHpn4xNiz2iQ5t7daGvE0FeM0WgniwHXWVAck3M/1AndvE Gsm8112yktNhV1BSnAjzV0p24qIPY7wjEe3NgjU4qzdtQHUoWtRyk4wNVUVer0aWL6V4D2KAxdq rcTkqXtngRyZxjDjsRsPI7w2xadRyw1Esm1D38wMBM25JFCdq6RWjQL9bUc/98KUSI06w3pHpa3 ds4NccvFJuZrCICd8xgLuXgA+84qzV7mvrjTp5S4gv8KdzOOMhCVeSe1kP2g6eYtOqoRHA6glcu kRmJPf4= X-Received: by 2002:a05:7022:e11:b0:128:d752:e074 with SMTP id a92af1059eb24-12a96e490a2mr1164070c88.1.1774438746920; Wed, 25 Mar 2026 04:39:06 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ranier Vilela Date: Wed, 25 Mar 2026 08:38:55 -0300 X-Gm-Features: AQROBzByGy4KEKI2iWxyzX48Ieau0rRsT4Wny8q01qvo_4c_GE0JQHuzdptnv5o Message-ID: Subject: Re: Avoid multiple calls to memcpy (src/backend/access/index/genam.c) To: lakshmi Cc: Bryan Green , Pg Hackers Content-Type: multipart/alternative; boundary="0000000000002f9bf7064dd7b78b" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000002f9bf7064dd7b78b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi. Em qua., 25 de mar. de 2026 =C3=A0s 08:26, lakshmi escreveu: > > 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 t= he > stable runs (excluding those affected by checkpoints). > > Thanks. > > - > > 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=E2=80=99t obs= erve a > consistent performance improvement with the patch under this workload.= The > differences appear to be within normal run-to-run variation. > > I agree. > - > > 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 beh= aves > with workloads involving larger numbers of keys or different access > patterns. > > I believe it's unnecessary; I think it's been clearly demonstrated that there has been no improvement, so it's not worth it. > - > > Please let me know if you=E2=80=99d like me to try any additional scen= arios. > > Thank you for testing. For me, the lesson here is that this is the first time I've seen that unloop doesn't work any better. best regards, Ranier Vilela --0000000000002f9bf7064dd7b78b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi.

Em qua., 25 de mar. de 2026 = =C3=A0s 08:26, lakshmi <lakshm= igcdac@gmail.com> escreveu:

Hi,

Thanks for the s= uggestion and for the earlier discussion.

Could you repeat the tests without enable-debug?
<= /blockquote>
I repeated the tests using a non-debug (optimiz= ed) build of PostgreSQL (19devel), built without --enabl= e-debug.=C2=A0

Test setup:

  • Debian Linux (x8= 6_64)

  • gcc 12.2.0

  • AMD Ryzen 5 7535U (6 cores / 12 threads)

  • pgbench scale factor 1

  • comm= and: p= gbench -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).

<= /div>
Thanks.
=C2=A0
  • Results:

    Original:
    TPS: ~1047Latency: ~9.5 ms

    Patche= d:
    TPS: ~1040
    Latency: ~9.6 ms

    From these runs, the results are quite close, and I didn=E2= =80=99t observe a consistent performance improvement with the patch under t= his workload. The differences appear to be within normal run-to-run variati= on.

=C2=A0I = agree.

  • It may be= that this change has limited impact in typical cases where the number of k= eys is small. It would be interesting to see how it behaves with workloads = involving larger numbers of keys or different access patterns.

  • I believe it's unnec= essary; I think it's been clearly demonstrated that there has been no i= mprovement, so it's not worth it.

    • Please let me know if you=E2=80=99d like me to try an= y additional scenarios.

    Thank you for testing.

    For me, the les= son here is that this is the first time I've seen that unloop doesn'= ;t work any better.

    best regards,
    Ranier= Vilela
    --0000000000002f9bf7064dd7b78b--