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 1vO36d-007aMn-1B for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Nov 2025 00:09:59 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vO36b-00CoyF-2T for pgsql-hackers@arkaria.postgresql.org; Wed, 26 Nov 2025 00:09:58 +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 1vO36b-00Coxz-0z for pgsql-hackers@lists.postgresql.org; Wed, 26 Nov 2025 00:09:57 +0000 Received: from mail-pg1-x531.google.com ([2607:f8b0:4864:20::531]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1vO36X-001Thu-2k for pgsql-hackers@postgresql.org; Wed, 26 Nov 2025 00:09:55 +0000 Received: by mail-pg1-x531.google.com with SMTP id 41be03b00d2f7-bde0f62464cso1026335a12.2 for ; Tue, 25 Nov 2025 16:09:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=enterprisedb.com; s=google; t=1764115793; x=1764720593; 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=ikYlIXehQKaYPxOTatdxe2HmNFqPU1OpKEluJfwfjp4=; b=QlD5b1eYFUYLej58fWHFhwkzL+lFYBcK73mZMIhpoCCQDO+Wwtjqv0Zj6d6Z0P+FtI MVQo3rI1UfAZYA3SRGx1Ra1ivVROt2xsOR05YK+wjZST/m4D6VGSztWYSuLjh/Ll53Z6 CXaC6wiPXqwQfMLT+U0xw/hPY2enI35Gt/bN01nfH5pRvjiUGvTcFLuJchDfV7bCU7/L zZcsT+dO9sobAQccrXUD/RbKetcYEF152uFe9bojYDkFcIaJm/fZPy8TdQjxRzKHFLsY ILiGnXl1Zu48eqEhP6/eVsHcoZWwUnuWDoQVSLs+AeQnFI+vfPmRP/cfmcrn0miPsaaP ACHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1764115793; x=1764720593; 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=ikYlIXehQKaYPxOTatdxe2HmNFqPU1OpKEluJfwfjp4=; b=J/el8K6siLiLUDcw1G8Xe8wEdVsptlY2ni1Y0GZLc6RcIdTjz70oGuERitmODZschC iVDgpv/7hwu2lOmbDwtfqdsZNujoJ+1M8cacCAYvxLTXFS93V7iLokMnZAs6ESUkuwXc rkg1VD0PjCTP+bWIVfdb0tks2tvFmofd9DgtZKfor+6gOYLN0/SvaKUFLtSkDUC0OIFs wgcOoWl/ewV0G3u1zxbAYY+1BcpGhHc4ZZgyqCcs5aRVX760wyZFNH0r/XxkHP29tAoa PioiolJ3DucDJxSIlofOJ7TktsMonbPYymjU/SqEmgq247o4Cdoj4Q8/rvI69tUIFfaF +WtA== X-Forwarded-Encrypted: i=1; AJvYcCWQMnVIFiRV2+Hj2woG+vuo4zb69tzqvc3Tua1NBhG/YVUt2kUkUHKkPsDF62qgY8wUHZbeaG8EZpZLYyoQ@postgresql.org X-Gm-Message-State: AOJu0YyVtajUQFGIqiXtoRUxnDaSh03IlDBqXPiuTDTHWHzJvud5CEAE NctPBOWW0ZfWnOwyiWQeX0+64zis56CFEs54/kg70aYivOyN9xV4dfBWDI+MSywuJ9uKV2hZnP9 3d/DexwfrFgKPaBBLp6Z4GSdotsjiXSR8VkFBvxZK X-Gm-Gg: ASbGncu3799nXbl36PYVOQtBz2CnY111Q2lntoYizhuOStp1Uko1HcrjRNE2li6AWWa I2I9UQOHTSHPC3ckJMGH5rAJdbOvVIHkLyNKSSd4TtSZYUcBjaQTtsScYAnICRHTbl6lgfh85MD vpOdIPVZmjG1+22Bu2fCLNt389laxV+pueoW0eUtnTwRrCavq5/wY5RgvxczTZ2tDOp3u5W6xxP Prqm7+isn9gAZVw4GgyuZWcZkxj0StPKM+ZBWyZEMGxQ3vctM1h8V7gZDSPUH3DfeMHIIY= X-Google-Smtp-Source: AGHT+IGxhpdvYeY+6jwh8hjjujtelyKLOlUfmFixyEu23HS60fcMsX4SCgMPTTaN66cTRDnbwSiiNWkr2Bw1M9+ZQj8= X-Received: by 2002:a05:7301:1f0e:b0:2a4:4324:7d2d with SMTP id 5a478bee46e88-2a719d5a99bmr14672689eec.22.1764115793248; Tue, 25 Nov 2025 16:09:53 -0800 (PST) MIME-Version: 1.0 References: <8e226753-57af-489a-bfbe-caa23dd71286@dunslane.net> In-Reply-To: From: Manni Wood Date: Tue, 25 Nov 2025 18:09:42 -0600 X-Gm-Features: AWmQ_bkVMlyGVPLWu3fP9flWCSrfVOpUQfOLQ_kqTXg9LUBxYcFYEP2tyuzpqrM Message-ID: Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD To: Nathan Bossart Cc: Nazir Bilal Yavuz , Andrew Dunstan , Shinya Kato , KAZAR Ayoub , PostgreSQL-development Content-Type: multipart/alternative; boundary="0000000000003313950644743796" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --0000000000003313950644743796 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello. I tried Ayoub Kazar's test files again, using Nazir Bilal Yavuz's v3 patches, but with one difference since my last attempt: this time, I used 5 million lines per file. For each 5 million line file, I ran the import 5 times and averaged the results. (I found that even using 1 million lines could sometimes produce surprising speedups where the newer algorithm should be at least a tiny bit slower than the non-simd version.) The text file with no special characters is 30% faster. The CSV file with no special characters is 39% faster. The text file with roughly 1/3rd special characters is 0.5% slower. The CSV file with roughly 1/3rd special characters is 2.7% slower. 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 50% faster. The CSV file was still 13% faster. On Mon, Nov 24, 2025 at 3:59=E2=80=AFPM Nathan Bossart wrote: > On Thu, Nov 20, 2025 at 03:55:43PM +0300, Nazir Bilal Yavuz wrote: > > On Thu, 20 Nov 2025 at 00:01, Nathan Bossart > wrote: > >> + /* Load a chunk of data into a vector register */ > >> + vector8_load(&chunk, (const uint8 *) > ©_input_buf[input_buf_ptr]); > >> > >> In other places, processing 2 or 4 vectors of data at a time has prove= n > >> faster. Have you tried that here? > > > > Sorry, I could not find the related code piece. I only saw the > > vector8_load() inside of hex_decode_safe() function and its comment > > says: > > > > /* > > * We must process 2 vectors at a time since the output will be half th= e > > * length of the input. > > */ > > > > But this does not mention any speedup from using 2 vectors at a time. > > Could you please show the related code? > > See pg_lfind32(). > > -- > nathan > --=20 -- Manni Wood EDB: https://www.enterprisedb.com --0000000000003313950644743796 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello.

I tried Ayoub Kazar's test f= iles again, using Nazir Bilal Yavuz's v3 patches, but with one differen= ce since my last attempt: this time, I used 5 million lines per file. For e= ach 5 million line file, I ran the import 5 times and averaged the results.=

(I found that even using 1 million lines could so= metimes produce surprising speedups where the newer algorithm should be at = least a tiny bit slower than the non-simd version.)

The text file with no special characters is 30% faster. The CSV file with= no special characters is 39% faster. The text file with roughly 1/3rd spec= ial characters is 0.5% slower. The CSV file with roughly 1/3rd special char= acters is 2.7% slower.

I also tried files that alt= ernated lines with no special characters and lines with 1/3rd special chara= cters, 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/d= on't-try-simd housekeeping code. The text file was still 50% faster. Th= e CSV file was still 13% faster.


<= br>
On Mon, Nov 24, 2025 at 3:59=E2=80=AFPM Nathan Bossart <= nathandbossart@gmail.com>= ; wrote:
On Thu,= Nov 20, 2025 at 03:55:43PM +0300, Nazir Bilal Yavuz wrote:
> On Thu, 20 Nov 2025 at 00:01, Nathan Bossart <nathandbossart@gmail.com> w= rote:
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 /* Load a chunk of data= into a vector register */
>> +=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 vector8_load(&chunk= , (const uint8 *) &copy_input_buf[input_buf_ptr]);
>>
>> In other places, processing 2 or 4 vectors of data at a time has p= roven
>> faster.=C2=A0 Have you tried that here?
>
> Sorry, I could not find the related code piece. I only saw the
> vector8_load() inside of hex_decode_safe() function and its comment > says:
>
> /*
>=C2=A0 * We must process 2 vectors at a time since the output will be h= alf the
>=C2=A0 * length of the input.
>=C2=A0 */
>
> But this does not mention any speedup from using 2 vectors at a time.<= br> > Could you please show the related code?

See pg_lfind32().

--
nathan


--
-- Manni Wood EDB: https://www.enterprisedb.com
--0000000000003313950644743796--