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 1vOGPE-00Hb14-39 for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Nov 2025 14:22:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vOGPD-00Gzu9-1l for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Nov 2025 14:22:03 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vOGPD-00Gzu1-0a for pgsql-hackers@lists.postgresql.org; Wed, 26 Nov 2025 14:22:03 +0000 Received: from mail-pg1-x534.google.com ([2607:f8b0:4864:20::534]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vOGPA-001cR3-2b for pgsql-hackers@postgresql.org; Wed, 26 Nov 2025 14:22:02 +0000 Received: by mail-pg1-x534.google.com with SMTP id 41be03b00d2f7-bc09b3d3b06so3809776a12.2 for ; Wed, 26 Nov 2025 06:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1764166917; x=1764771717; 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=2esaDr0dliBrdUnE8Kn58M1Zzah/RwnHNSt6k5yegYk=; b=UHU7vw5cXhGno7mqnBhqmEbtQXP7+Ip57JdTOxCHOMI4PFYpJjPb08CcA9avq/rngu B6mxg1Zb2JDTWQzGISGJgZYKHLczIIbHdKXhPPIlB2AzLTNJiVtBPdZ5NAlroW1WulWN 2O2QB4fnDQJn1XXKgEd//Hm9WcfEnehWMBfRR06l6cR/bqZjt+5iG76FQUnSrIkWPv5r Z8bFGsRlBA6ttYgPGAxq8WwUhDiUUyTCKXCNqkhdYztqSXIqSkuQfWwOz97VQKgktKrJ SLCQItd2vKMOyOBSfn1luQDV5vm9giry9hGBKeB6fyPUZ2Q8i/sfWy4YBAwafC6wKwxW 7R7Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764166917; x=1764771717; 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=2esaDr0dliBrdUnE8Kn58M1Zzah/RwnHNSt6k5yegYk=; b=KrMvgtArTeVXsxJNaOBF8Hn6czWt8jQSGwK63YZPkt/DJAU3tW55WvtR4jiydcrLhE SozY1Qysop41biOsDwYT6YtGgij4HI3Jg1fmlMtMBUp7kGQEB1wL/1of+Cf089KjtWxU 7sfCuBq+KTf+S7LAKOVoEjVtq04Pq2vZxg9pNn0dFBVQ6WkHUSl2l9Olf6xruiTDbgnH bI+aY/7EhBbKlQz/uIKnrKZYiq9EeOn4rlBidj48NntbNFlgRbCPPr3dq/NmFhrr9REm wcjCYpxGdnl6wqKk2Pnqv0kR8dw+mx1PJZ21tUEHEZJIYCp3vYnBovZuCdly5H3MF7VQ GJFg== X-Forwarded-Encrypted: i=1; AJvYcCWew0zXR3ogUDr0567NnigCHpnvRzjBHMjmm/czbsY++I3ZLMIl2sxNczvpH6SRO4Ywzz32B5vi/JjN1bJL@postgresql.org X-Gm-Message-State: AOJu0YzhbtJBF6rJdQAbGugP7nABCPZfgxh4umoNxtVaTk3hCO0prVPK 4CdPm/ndvpP2xLNFNQmIXII1eWGZP/uhoISGm2gNvwrw4Wq4dtlLaBcJvaMyw+9N0cysaFxSwJS N68KYSOZ43Cg1DiA4WubQBuS4L/8eeJHTWxWI5b2A X-Gm-Gg: ASbGncvW4mKufqQ2xiuLsjjTUhfNALbpkWuv6VE38fcY2tii+WS0OV1SI5oMieZJ59i tb0vsIIHQA8pJzAxSVzr8CbitUv4DaPIo3t/iBWGWsGEOUBNjPK6FHCozMsUkEJeA3VT4UrONxK w42GMm6fcIKVB5vjd8povNjbLxKYRyDWtBl6yU3jjH+yoZ8OXAr+8fDOIthgw3WmjcAnXR8Xkiv u8NCotXdaM+n/KFb9rpPI8CE7847xbWwkOBgFRQ7ZKUTQ4j2QTHaxIxNZiQbxu3GyTo0bs= X-Google-Smtp-Source: AGHT+IEv4A3MxTihc4yL1Gl/et1NdNzupl/bHkM+kjy5biFuC8jROACXXzY+zY5Xc9jsWBKrIhAv9F6JJralG7Tck4Y= X-Received: by 2002:a05:7300:538c:b0:2a4:3593:4669 with SMTP id 5a478bee46e88-2a941572fd6mr4978549eec.5.1764166917446; Wed, 26 Nov 2025 06:21:57 -0800 (PST) MIME-Version: 1.0 References: <5d81fbbb-7609-4445-9bc4-8af211fb7674@dunslane.net> <8e226753-57af-489a-bfbe-caa23dd71286@dunslane.net> In-Reply-To: From: Manni Wood Date: Wed, 26 Nov 2025 08:21:46 -0600 X-Gm-Features: AWmQ_bnwZRoHjzbUK-XeDNk3H0joa5gkS5XerHI0RD_CmvzVt-Ir3DEjt3ahJMI Message-ID: Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD To: KAZAR Ayoub Cc: Nathan Bossart , Nazir Bilal Yavuz , Andrew Dunstan , Shinya Kato , PostgreSQL-development Content-Type: multipart/alternative; boundary="000000000000706af10644801e33" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --000000000000706af10644801e33 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Nov 26, 2025 at 5:51=E2=80=AFAM KAZAR Ayoub wrote= : > Hello, > On Wed, Nov 19, 2025 at 10:01=E2=80=AFPM Nathan Bossart > wrote: > >> On Tue, Nov 18, 2025 at 05:20:05PM +0300, Nazir Bilal Yavuz wrote: >> > Thanks, done. >> >> I took a look at the v3 patches. Here are my high-level thoughts: >> >> + /* >> + * Parse data and transfer into line_buf. To get benefit from >> inlining, >> + * call CopyReadLineText() with the constant boolean variables. >> + */ >> + if (cstate->simd_continue) >> + result =3D CopyReadLineText(cstate, is_csv, true); >> + else >> + result =3D CopyReadLineText(cstate, is_csv, false); >> >> I'm curious whether this actually generates different code, and if it >> does, >> if it's actually faster. We're already branching on cstate->simd_contin= ue >> here. > > I've compiled both versions with -O2 and confirmed they generate differen= t > code. When simd_continue is passed as a constant to CopyReadLineText, the > compiler optimizes out the condition checks from the SIMD path. > A small benchmark on a 1GB+ file shows the expected benefit which is > around 6% performance improvement. > I've attached the assembly outputs in case someone wants to check > something else. > > > Regards, > Ayoub Kazar > Correction to my last post: I also tried files that alternated lines with no special characters and lines with 1/3rd special characters, thinking I could force the algorithm to continually check whether or not it should use simd and therefore force more overhead in the try-simd/don't-try-simd housekeeping code. The text file was still 20% faster (not 50% faster as I originally stated --- that was a typo). The CSV file was still 13% faster. Also, apologies for posting at the top in my last e-mail. --=20 -- Manni Wood EDB: https://www.enterprisedb.com --000000000000706af10644801e33 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Nov 26,= 2025 at 5:51=E2=80=AFAM KAZAR Ayoub <ma_kazar@esi.dz> wrote:
Hello,
On Wed, Nov 19,= 2025 at 10:01=E2=80=AFPM Nathan Bossart <nathandbossart@gmail.com> wrote:
=
On Tue, Nov 18, 2025 at 05:20:05PM +0300, Nazir Bilal Yavuz wrote:<= br> > Thanks, done.

I took a look at the v3 patches.=C2=A0 Here are my high-level thoughts:

+=C2=A0 =C2=A0 /*
+=C2=A0 =C2=A0 =C2=A0* Parse data and transfer into line_buf. To get benefi= t from inlining,
+=C2=A0 =C2=A0 =C2=A0* call CopyReadLineText() with the constant boolean va= riables.
+=C2=A0 =C2=A0 =C2=A0*/
+=C2=A0 =C2=A0 if (cstate->simd_continue)
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 result =3D CopyReadLineText(cstate, is_csv, tr= ue);
+=C2=A0 =C2=A0 else
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 result =3D CopyReadLineText(cstate, is_csv, fa= lse);

I'm curious whether this actually generates different code, and if it d= oes,
if it's actually faster.=C2=A0 We're already branching on cstate-&g= t;simd_continue
here.
I've compiled both versions = with -O2 and confirmed they generate different code. When=C2= =A0simd_continue is passed as a constant to CopyReadLineText, = the compiler optimizes out the condition checks from the=20 SIMD path.=C2=A0
A small benchmark on a 1GB+ file shows the expected ben= efit which is around 6%=20 performance improvement.
I've attached the assembly outputs=C2=A0in case someone wants to check something else.


Regards,
Ayoub Kaza= r

Correction to my last = post:

I also tried files that alternated lines wit= h no special characters and lines with 1/3rd special characters, thinking I= could force the algorithm to continually check whether or not it should us= e simd and therefore force more overhead in the try-simd/don't-try-simd= housekeeping code. The text file was still 20% faster (not 50% faster as I= originally stated --- that was a typo). The CSV file was still 13% faster.=

Also, apologies for posting at the top in my last= e-mail.
--
-- Manni Wood EDB: https://www.enterprisedb.com
--000000000000706af10644801e33--