| 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
| 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() |