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.94.2) (envelope-from ) id 1uljOm-004jhf-Nv for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Aug 2025 07:26:20 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uljOk-005mEz-EQ for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Aug 2025 07:26:18 +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.94.2) (envelope-from ) id 1uljOk-005mEq-3v for pgsql-hackers@lists.postgresql.org; Tue, 12 Aug 2025 07:26:18 +0000 Received: from mail-qt1-x833.google.com ([2607:f8b0:4864:20::833]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.96) (envelope-from ) id 1uljOh-0009vN-38 for pgsql-hackers@postgresql.org; Tue, 12 Aug 2025 07:26:17 +0000 Received: by mail-qt1-x833.google.com with SMTP id d75a77b69052e-4b0770954faso80644221cf.1 for ; Tue, 12 Aug 2025 00:26:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1754983573; x=1755588373; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=KkKmgcJB46SI9Cw0pRvf+ICjKxAaxg3NXbNLz+aB7f8=; b=DH4dBLP6vxfs/hDjWDboyB98glcor1kOIGFdJHiZejxS9UryH9w/wbycEAnpH4X3Rr qtP6uT4wN9N1EdCAXW4MdjHrhORTBIz0SUcFPkyNDxHgTcZss6AbTqpod7g4Kqk5YaCd evkMMbtJDA0/28h4jBUjE/dqXlfzBW6pszgpM2G7gaRtJbl4LrA0SsrUmqroOGAWrFGv 606gidUp9BBnxUHlbdhS4zzIrcdX6NVCGXINhCuFaXPQdzY6Qh0xG9VtGNtoTb7QugIz h33amZW1tC/uwX8/olH+3WROshfXSqUz0OhAS4eZuALZ9p+ddcctFzkZ69+tQK8n3ytG tAfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1754983573; x=1755588373; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=KkKmgcJB46SI9Cw0pRvf+ICjKxAaxg3NXbNLz+aB7f8=; b=EeqjVXQpIlxz+6zxW4hXy3DSfZzuc1CYUhkXQmUeUwaDiDfrPs0hQ1Lx3BG3hNmDLZ eZ+Ig/W0cVn/h1zPwfB3RPxEPOW/b6QIKvVSvrpyJNQxwlWu8b6s4MWH2TEpeKTHNGEu 8S61AfftAfqOfFNLPLshEqYRVSCCktjKGsTkfPWXdFf8HITXh8//BUPxKVrH59FYNr85 OvqnCRA0UB3LI9ERiJ60fvggQbIrM/tidKk3a9C1jRifOdpUQoM1m6Q1Cl26x8BcWyr0 Xik895j6gTLItdzGwPYW7Dlcinw12v81nA/9T068EuKzBJyiX8v1Vd8lrpH7vRS+B2cT 44Tg== X-Gm-Message-State: AOJu0Yzy1m3qKkq5HS+hNZG3o8JQr+rzpM4a/f9IC7Kt/a2lYdjFG+7+ JkKuAQi5dJ+F9Eeo3BEdo8vapLGAz/cK2DLFTbAmT+DUa6WZwIA92kX2C6kXKZs83uXdxpb3l0w EbVf+GGVPOQcW28OaA+h0R5nBG/bhNQ== X-Gm-Gg: ASbGncv0LqikUAAdgDl/WY5If1k5hNFLCl9DBnS1ZkskKYqPmdUMxhNtLXzj6vj1Zsc IKHuFvLUi4/sbwaqq5MEf4fYNJm58ntqnK/IehGeQ0RTPPf1fLMFh3Kt+kI/MuemS1CTE1tYc3w RXNe0ggwUzdBFsd50piDHUmCwBlvKgKInKVU8g19SQvlRivqG3PCz2e1Dlhbm6b7zVmk0ZxQ5jK 33w84c= X-Google-Smtp-Source: AGHT+IFvTb5ClV6nkqnE70NadWkyvsWp93pZZaIJy3raHtsZpCyQPJsX2cZXxsnwPDm9+ohaahxFet84ShrKpjmd370= X-Received: by 2002:ac8:598e:0:b0:4b0:8ecd:412 with SMTP id d75a77b69052e-4b0ecc50f75mr36826741cf.38.1754983572697; Tue, 12 Aug 2025 00:26:12 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Shinya Kato Date: Tue, 12 Aug 2025 16:25:36 +0900 X-Gm-Features: Ac12FXxQ2jD6N7NP7DTMW4DALlYaEDuOB28N_6dFypyRWL8bwhi2_zDrrNiFVSY Message-ID: Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD To: Nazir Bilal Yavuz Cc: pgsql-hackers@postgresql.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Thu, Aug 7, 2025 at 8:15=E2=80=AFPM Nazir Bilal Yavuz wrote: > > Hi, > > Thank you for working on this! > > On Thu, 7 Aug 2025 at 04:49, Shinya Kato wrote: > > > > Hi hackers, > > > > I have implemented SIMD optimization for the COPY FROM (FORMAT {csv, > > text}) command and observed approximately a 5% performance > > improvement. Please see the detailed test results below. > > I have been working on the same idea. I was not moving input_buf_ptr > as far as possible, so I think your approach is better. Great. I'm looking forward to working with you on this feature implementati= on. > Also, I did a benchmark on text format. I created a benchmark for line > length in a table being from 1 byte to 1 megabyte.The peak improvement > is line length being 4096 and the improvement is more than 20% [1], I > saw no regression on your patch. Thank you for the additional benchmarks. > I have a couple of ideas that I was working on: > --- > > + * However, SIMD optimization cannot be applied in the following= cases: > + * - Inside quoted fields, where escape sequences and closing qu= otes > + * require sequential processing to handle correctly. > > I think you can continue SIMD inside quoted fields. Only important > thing is you need to set last_was_esc to false when SIMD skipped the > chunk. That's a clever point that last_was_esc should be reset to false when a SIMD chunk is skipped. You're right about that specific case. However, the core challenge is not what happens when we skip a chunk, but what happens when a chunk contains special characters like quotes or escapes. The main reason we avoid SIMD inside quoted fields is that the parsing logic becomes fundamentally sequential and context-dependent. To correctly parse a "" as a single literal quote, we must perform a lookahead to check the next character. This is an inherently sequential operation that doesn't map well to SIMD's parallel nature. Trying to handle this stateful logic with SIMD would lead to significant implementation complexity, especially with edge cases like an escape character falling on the last byte of a chunk. > + * - When the remaining buffer size is smaller than the size of = a SIMD > + * vector register, as SIMD operations require processing data= in > + * fixed-size chunks. > > You run SIMD when 'copy_buf_len - input_buf_ptr >=3D sizeof(Vector8)' > but you only call CopyLoadInputBuf() when 'input_buf_ptr >=3D > copy_buf_len || need_data' so basically you need to wait at least the > sizeof(Vector8) character to pass for the next SIMD. And in the worst > case; if CopyLoadInputBuf() puts one character less than > sizeof(Vector8), then you can't ever run SIMD. I think we need to make > sure that CopyLoadInputBuf() loads at least the sizeof(Vector8) > character to the input_buf so we do not encounter that problem. I think you're probably right, but we only need to account for sizeof(Vector8) when USE_NO_SIMD is not defined. > What do you think about adding SIMD to CopyReadAttributesText() and > CopyReadAttributesCSV() functions? When I add your SIMD approach to > CopyReadAttributesText() function, the improvement on the 4096 byte > line length input [1] goes from 20% to 30%. Agreed, I will. > I shared my ideas as a Feedback.txt file (.txt to stay off CFBot's > radar for this thread). I hope these help, please let me know if you > have any questions. Thanks a lot! On Mon, Aug 11, 2025 at 5:52=E2=80=AFPM Nazir Bilal Yavuz wrote: > > Hi, > > On Thu, 7 Aug 2025 at 14:15, Nazir Bilal Yavuz wrote= : > > > > On Thu, 7 Aug 2025 at 04:49, Shinya Kato wrot= e: > > > > > > I have implemented SIMD optimization for the COPY FROM (FORMAT {csv, > > > text}) command and observed approximately a 5% performance > > > improvement. Please see the detailed test results below. > > > > Also, I did a benchmark on text format. I created a benchmark for line > > length in a table being from 1 byte to 1 megabyte.The peak improvement > > is line length being 4096 and the improvement is more than 20% [1], I > > saw no regression on your patch. > > I did the same benchmark for the CSV format. The peak improvement is > line length being 4096 and the improvement is more than 25% [1]. I saw > a 5% regression on the 1 byte benchmark, there are no other > regressions. Thank you. I'm not too concerned about a regression when there's only one byte per line. > > What do you think about adding SIMD to CopyReadAttributesText() and > > CopyReadAttributesCSV() functions? When I add your SIMD approach to > > CopyReadAttributesText() function, the improvement on the 4096 byte > > line length input [1] goes from 20% to 30%. > > I wanted to try using SIMD in CopyReadAttributesCSV() as well. The > improvement on the 4096 byte line length input [1] goes from 25% to > 35%, the regression on the 1 byte input is the same. Yes, I'm on it. I'm currently adding the SIMD logic to CopyReadAttributesCSV() as you suggested. I'll share the new version of the patch soon. -- Best regards, Shinya Kato NTT OSS Center