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

From: Nathan Bossart <nathandbossart(at)gmail(dot)com>
To: Greg Burd <greg(at)burd(dot)me>
Cc: Nazir Bilal Yavuz <byavuz81(at)gmail(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-08 20:58:25
Message-ID: aqB28YZZHC2xnZMq@nathan
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 08, 2026 at 11:58:42AM -0400, Greg Burd wrote:
> The test writes one full input buffer (INPUT_BUF_SIZE, 65536 bytes) down a
> COPY FROM PROGRAM pipe: a 65524-byte line, then a complete \. marker, then
> 8 trailing bytes. That leaves 11 bytes unexamined when the SIMD path wants
> to refill, which is under sizeof(Vector8) and already holds the whole
> marker. The writer then dribbles a byte every 50ms and keeps the pipe open,
> so a speculative load blocks rather than seeing EOF. statement_timeout
> bounds the failure, so a regression fails the test instead of hanging the
> suite. Skipped on Windows, where the blocking pipe and SIGPIPE behavior
> isn't reliable.

I'm not sure this particular corner case deserves its own TAP test. IMHO
that is disproportionately expensive. It really only serves to prevent us
from removing the backslash scan from the SIMD path, which I don't think
we're likely to do. Furthermore, I'm not aware of any existing examples
where a test writes and then invokes its own Perl script, and I can't get
too excited about being the first to commit something like that. So, I'd
prefer to leave this test out for now. If the new test fit cleanly into an
existing suite or was less magical, I might be more eager to include it,
but it's probably still unlikely to be worth the energy and maintenance
risk.

--
nathan

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2026-09-08 21:12:44 Re: REPACK (CONCURRENTLY) can crash a logical decoding session
Previous Message Zsolt Parragi 2026-09-08 20:42:55 Re: Introducing find_all_inheritors_ordered()