Re: Speed up COPY FROM text/CSV parsing using SIMD

From: "Greg Burd" <greg(at)burd(dot)me>
To: "Nazir Bilal Yavuz" <byavuz81(at)gmail(dot)com>, "Nathan Bossart" <nathandbossart(at)gmail(dot)com>
Cc: "Manni Wood" <manni(dot)wood(at)enterprisedb(dot)com>, "KAZAR Ayoub" <ma_kazar(at)esi(dot)dz>, "Neil Conway" <neil(dot)conway(at)gmail(dot)com>, "Andrew Dunstan" <andrew(at)dunslane(dot)net>, "Shinya Kato" <shinya11(dot)kato(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD
Date: 2026-09-01 04:41:20
Message-ID: 78e736c8-7f4e-46c2-9fcf-a6839e393d64@app.fastmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hey Nathan, Nazir,

I've also reproduced the error and confirmed the patch addresses it
cleanly.

For anyone following along, the mechanism: commit e0a3a3fd53 added
CopyReadLineTextSIMDHelper, which refills the input buffer once fewer
than sizeof(Vector8) bytes remain:

if (copy_buf_len - input_buf_ptr < sizeof(Vector8)) /* reads ahead */

whereas scalar CopyReadLineText only refills when actually empty:

if (input_buf_ptr >= copy_buf_len || need_data)

That difference is the issue. CopyConvertBuf() deliberately tolerates an
invalid byte sequence after the \. end-of-copy marker (see the comment
near its convertedlen == 0 block), deferring the error. But
CopyLoadInputBuf() raises it the moment input_reached_error is set. The
SIMD read-ahead reaches that raise before the scalar loop has consumed
\., so a file ending in \.\n<valid bytes><invalid byte> errors out where
the scalar path would have stopped cleanly at \.

+1 on adding the reproducer as a test and calling it good.

best,

-greg

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2026-09-01 04:58:57 Re: Adding a stored generated column without long-lived locks
Previous Message Nisha Moond 2026-09-01 04:27:07 Re: Proposal: Conflict log history table for Logical Replication