Date: Tue, 8 Sep 2026 10:24:59 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Nazir Bilal Yavuz <byavuz81@gmail.com>
Cc: Greg Burd <greg@burd.me>, KAZAR Ayoub <ma_kazar@esi.dz>,
	Neil Conway <neil.conway@gmail.com>,
	Andrew Dunstan <andrew@dunslane.net>,
	Shinya Kato <shinya11.kato@gmail.com>,
	pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD
Message-ID: <aqAoyyC1Qlx62KQ0@nathan>
References: 
 <CAN55FZ1b1Jstrr-K7xcXY9z1ObDRxi48dAhwdHpTZn1C=S-jHA@mail.gmail.com>
 <b26a1cf8-335d-4054-90ad-d94457c45947@app.fastmail.com>
 <abRKUiInG6Gu728Q@nathan>
 <apWOr1kgVSqweBnU@nathan>
 <CAN55FZ1utgaKb1DbW7tr+2=s4Hm1yiCEeNDY9m=qP_M_drafCg@mail.gmail.com>
 <78e736c8-7f4e-46c2-9fcf-a6839e393d64@app.fastmail.com>
 <CAN55FZ0UJg+9wcyTCUG656c9DKCNvTGVuuVe4EMMVCHPwGS4aQ@mail.gmail.com>
 <apcmTvBmA27RoyYL@nathan>
 <CAN55FZ1qFb4Yo3-MWeQfGQnu1_Ksx4xcFC2m3hyw8a--+eHQYQ@mail.gmail.com>
 <CAN55FZ3U2waD=5ZuVmju-HtZ4cO4onxHN4jXskk8Y11M6o3NOQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="6iEgN7+SXNUlzhJ5"
Content-Disposition: inline
In-Reply-To: 
 <CAN55FZ3U2waD=5ZuVmju-HtZ4cO4onxHN4jXskk8Y11M6o3NOQ@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/aqAoyyC1Qlx62KQ0%40nathan>
Precedence: bulk

--6iEgN7+SXNUlzhJ5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Tue, Sep 08, 2026 at 01:11:00PM +0300, Nazir Bilal Yavuz wrote:
> Here is an attempt to solve this problem. I ran Manni's script and saw
> a 1-2% slowdown on TEXT-wide inputs. It is still faster compared to
> the version without the SIMD patch; the slowdown is relative to the
> current master branch (which includes the SIMD patch).

Thanks for reporting.  Fable 5.1 suggests moving the check to
CopyLoadInputBuf() to avoid this small regression, which makes sense to me.
I've attached a new patch that does that.  This is definitely a bit of
hack, and I'm assuming we'll need to revisit this if we want to re-attempt
more sophisticated heuristics for when to use the SIMD path.  But IMHO this
is self-contained enough to be reasonable for v19.

-- 
nathan

--6iEgN7+SXNUlzhJ5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename=v2-0001-Fix-hangs-in-COPY-FROM-FORMAT-text.patch

From 2323f8bbc97467238859ece05f3b6da5524c7593 Mon Sep 17 00:00:00 2001
From: Nathan Bossart <nathan@postgresql.org>
Date: Tue, 8 Sep 2026 10:24:31 -0500
Subject: [PATCH v2 1/1] Fix hangs in COPY FROM (FORMAT text).

The SIMD path for this command reads ahead via CopyLoadInputBuf()
whenever fewer than sizeof(Vector8) bytes remain in the input
buffer, even if those bytes hold a complete end-of-copy marker.
If the input is a pipe whose writer has sent the marker but not
closed the pipe, that read blocks, and COPY waits for data it will
never use.  The scalar loop asks only for the bytes it needs, so
it stops at the marker without reading any further.

To fix, teach CopyLoadInputBuf() to decline a speculative load
when the caller's remaining bytes contain a backslash, which in
text mode might begin such a marker.  (CSV mode doesn't treat
\. as special, so it is unaffected.)  The SIMD path then hands
those bytes to the scalar loop, as it already does when a load
comes up short.  Checking for the marker in the SIMD helper itself
would be more direct, but a call there costs the compiler
registers on every line, which measurably slowed COPY of short
lines in my testing.

Oversight in commit e0a3a3fd53.

Author: Nazir Bilal Yavuz <byavuz81@gmail.com>
Discussion: https://postgr.es/m/CAN55FZ1qFb4Yo3-MWeQfGQnu1_Ksx4xcFC2m3hyw8a--%2BeHQYQ%40mail.gmail.com
Backpatch-through: 19
---
 src/backend/commands/copyfromparse.c | 22 ++++++++++++++++++----
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/src/backend/commands/copyfromparse.c b/src/backend/commands/copyfromparse.c
index 98bf30ef2e7..68088108c7c 100644
--- a/src/backend/commands/copyfromparse.c
+++ b/src/backend/commands/copyfromparse.c
@@ -652,16 +652,30 @@ CopyLoadRawBuf(CopyFromState cstate)
  * If INPUT_BUF_BYTES(cstate) > 0, the unprocessed bytes are moved to the start
  * of the buffer and then we load more data after that.
  *
- * If "speculative" is true, this function skips reporting any encoding or
- * conversion errors, provided there are still data for the caller to process.
- * Such callers must be prepared for this function to return without loading
- * anything.
+ * If "speculative" is true, the caller has not yet examined the data left in
+ * input_buf and needn't load more to make progress.  In that case, this
+ * function skips reporting any encoding or conversion errors, and in text
+ * mode it declines to read past a backslash, as that might begin an
+ * end-of-copy marker.  Such callers must be prepared for this function to
+ * return without loading anything.
  */
 static void
 CopyLoadInputBuf(CopyFromState cstate, bool speculative)
 {
 	int			nbytes = INPUT_BUF_BYTES(cstate);
 
+	/*
+	 * In text mode, a backslash among the bytes a speculative caller has yet
+	 * to examine might begin an end-of-copy marker.  The caller must find
+	 * that on its own, without waiting on input that may never arrive, as
+	 * from a pipe whose writer has sent the marker but not closed the pipe.
+	 * So in that case, just return without loading anything.
+	 */
+	if (speculative && cstate->opts.format == COPY_FORMAT_TEXT &&
+		memchr(cstate->input_buf + cstate->input_buf_index, '\\',
+			   nbytes) != NULL)
+		return;
+
 	/*
 	 * The caller has updated input_buf_index to indicate how much of the
 	 * input has been consumed and isn't needed anymore.  If input_buf is the
-- 
2.55.0


--6iEgN7+SXNUlzhJ5--