MIME-Version: 1.0
References: <aPkvi5P7kpA8oQKc@nathan> <5d81fbbb-7609-4445-9bc4-8af211fb7674@dunslane.net>
 <CAKWEB6qdyhN3EoUNAK23etXX-kXH-_79NNbTsKqtF1g1WkuaBQ@mail.gmail.com>
 <CA+K2RumMC+avYGSX-AWNeod3w+XOGHrVPz8HiqkvJj7AZ5tZXA@mail.gmail.com>
 <CAKWEB6pev=pNVi4qDYWS50N=YFrKRbjH1h=5F1bXpnK7WR5CYg@mail.gmail.com>
 <aRue0D4QQkUf2B_N@nathan> <CAOzEurTHCGL-Txqf5rxMsPgTF=dTCOsr=uhJdXebqjEJy-0L7g@mail.gmail.com>
 <CAN55FZ0+JZvKYVCnJqLhHaWF9eBGmTaF1BCEpttxw1aT3G_+Qw@mail.gmail.com>
 <8e226753-57af-489a-bfbe-caa23dd71286@dunslane.net> <CAN55FZ1XF=R7F7B__gq04rp2nQnJqs1yfExEXo4riWc68+Pe0w@mail.gmail.com>
 <aR4wDwNdLc5TmcQq@nathan> <CA+K2Rump8NoMRZRZ2r4jHXUJwByasy_c3_b0oaO+TLkSbMD-jw@mail.gmail.com>
 <CAKWEB6rLxPVtN4ffZ3CMTL518zhk_BWzzBt6ZE2oUSaErdphxA@mail.gmail.com>
 <CAKWEB6oO4gQd+UJBrU=uuUTE8Hv7GMznjMouvn0Lskr52UqjhQ@mail.gmail.com>
 <CAN55FZ0Nd9FL=aDSjOTJTeFAn8VNrZgWG+WbcHR+R7GkDMvUyw@mail.gmail.com>
 <CAN55FZ1fwKgGo2wEie1w2M2jzJko6cMi1NWD05Xm47_L9a3D+g@mail.gmail.com>
 <CAKWEB6oZdQhhBV3ojHLBwjQgKzfDw0fkqncurt9oi7vNsq41ww@mail.gmail.com> <CAN55FZ1p5UyUdTRO7iWR_ukjhJDOnpOR2rYNOq=+hcC45OuahQ@mail.gmail.com>
In-Reply-To: <CAN55FZ1p5UyUdTRO7iWR_ukjhJDOnpOR2rYNOq=+hcC45OuahQ@mail.gmail.com>
From: Neil Conway <neil.conway@gmail.com>
Date: Wed, 21 Jan 2026 15:49:59 -0500
Message-ID: <CAOW5sYZEx=fPw2wp7y2nK_-ifXFeYW4CTmFx_OQeoHFjG7rbHw@mail.gmail.com>
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD
To: Nazir Bilal Yavuz <byavuz81@gmail.com>
Cc: Manni Wood <manni.wood@enterprisedb.com>, KAZAR Ayoub <ma_kazar@esi.dz>, 
	Nathan Bossart <nathandbossart@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, 
	Shinya Kato <shinya11.kato@gmail.com>, 
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Content-Type: multipart/alternative; boundary="0000000000000342450648ec12c5"
Archived-At: <https://www.postgresql.org/message-id/CAOW5sYZEx%3DfPw2wp7y2nK_-ifXFeYW4CTmFx_OQeoHFjG7rbHw%40mail.gmail.com>
Precedence: bulk

--0000000000000342450648ec12c5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

A few suggestions:

* I'm curious if we'll see better performance on large inputs if we flush
to `line_buf` periodically (e.g., at least every few thousand bytes or so).
Otherwise we might see poor data cache behavior if large inputs with no
control characters get evicted before we've copied them over. See the
approach taken in escape_json_with_len() in utils/adt/json.c

* Did you compare the approach taken in the patch with a simpler approach
that just does

if (!(vector8_has(chunk, '\\') ||
      vector8_has(chunk, '\r') ||
      vector8_has(chunk, '\n') /* and so on, accounting for CSV / escapec /
quotec stuff */))
{
    /* skip chunk */
}

That's roughly what we do elsewhere (e.g., escape_json_with_len). It has
the advantage of being more readable, along with potentially having fewer
data dependencies.

Neil

On Wed, Dec 10, 2025 at 7:00=E2=80=AFAM Nazir Bilal Yavuz <byavuz81@gmail.c=
om>
wrote:

> Hi,
>
> On Wed, 10 Dec 2025 at 01:13, Manni Wood <manni.wood@enterprisedb.com>
> wrote:
> >
> > Bilal Yavuz (Nazir Bilal Yavuz?),
>
> It is Nazir Bilal Yavuz, I changed some settings on my phone and it
> seems that it affected my mail account, hopefully it should be fixed
> now.
>
> > I did not get a chance to do any work on this today, but wanted to than=
k
> you for finding my logic errors in counting special chars for CSV, and
> hacking on my naive solution to make it faster. By attempting Andrew
> Dunstan's suggestion, I got a better feel for the reality that the
> "housekeeping" code produces a significant amount of overhead.
>
> You are welcome! v4.1 has some problems with in_quote case in SIMD
> handling code and counting cstate->chars_processed variable. I fixed
> them in v4.2.
>
> --
> Regards,
> Nazir Bilal Yavuz
> Microsoft
>

--0000000000000342450648ec12c5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A few suggestions:<br><br>* I&#39;m curious if we&#39;ll s=
ee better performance on large inputs if we flush to `line_buf` periodicall=
y (e.g., at least every few thousand bytes or so). Otherwise we might see p=
oor data cache behavior if large inputs with no control characters get evic=
ted before we&#39;ve copied them over. See the approach taken in=C2=A0escap=
e_json_with_len() in utils/adt/json.c<div><br></div><div>* Did you compare =
the approach taken in the patch with a simpler approach that just does</div=
><div><br></div><div>if (!(vector8_has(chunk, &#39;\\&#39;) ||</div><div>=
=C2=A0 =C2=A0 =C2=A0 vector8_has(chunk, &#39;\r&#39;) ||</div><div>=C2=A0 =
=C2=A0 =C2=A0 vector8_has(chunk, &#39;\n&#39;) /* and so on, accounting for=
 CSV / escapec / quotec stuff */))</div><div>{</div><div>=C2=A0 =C2=A0 /* s=
kip chunk */</div><div>}</div><div><br></div><div>That&#39;s roughly what w=
e do elsewhere (e.g., escape_json_with_len). It has the advantage of being =
more readable, along with potentially having fewer data dependencies.</div>=
<div><br></div><div>Neil</div></div><br><div class=3D"gmail_quote gmail_quo=
te_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Dec 10, 2025 at=
 7:00=E2=80=AFAM Nazir Bilal Yavuz &lt;<a href=3D"mailto:byavuz81@gmail.com=
">byavuz81@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quo=
te" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204=
);padding-left:1ex">Hi,<br>
<br>
On Wed, 10 Dec 2025 at 01:13, Manni Wood &lt;<a href=3D"mailto:manni.wood@e=
nterprisedb.com" target=3D"_blank">manni.wood@enterprisedb.com</a>&gt; wrot=
e:<br>
&gt;<br>
&gt; Bilal Yavuz (Nazir Bilal Yavuz?),<br>
<br>
It is Nazir Bilal Yavuz, I changed some settings on my phone and it<br>
seems that it affected my mail account, hopefully it should be fixed<br>
now.<br>
<br>
&gt; I did not get a chance to do any work on this today, but wanted to tha=
nk you for finding my logic errors in counting special chars for CSV, and h=
acking on my naive solution to make it faster. By attempting Andrew Dunstan=
&#39;s suggestion, I got a better feel for the reality that the &quot;house=
keeping&quot; code produces a significant amount of overhead.<br>
<br>
You are welcome! v4.1 has some problems with in_quote case in SIMD<br>
handling code and counting cstate-&gt;chars_processed variable. I fixed<br>
them in v4.2.<br>
<br>
-- <br>
Regards,<br>
Nazir Bilal Yavuz<br>
Microsoft<br>
</blockquote></div>

--0000000000000342450648ec12c5--