MIME-Version: 1.0
References: 
 <CA+K2Runi_H2CBL0yMm3De2KqcR9RMA0HK5cLJjEhoNszC7myeg@mail.gmail.com>
 <aY5C6Xa5im72NF_Y@alap3.anarazel.de>
 <CA+K2Rum_QTZqTUrdMOL5hr-OOpCwGR_9Nj1z15BFObjktMOY6A@mail.gmail.com>
 <abBuKalOno33MQFw@nathan>
 <CA+K2Rum7+Jm2rm65K5msxaiAM8QTkhSNAYarPBP9O7nBXYo12Q@mail.gmail.com>
 <abmiNPQOqBrRlf_m@nathan>
 <CA+K2Rum-TB_iNzDWoXOJspf=jq0gd-wees8+9tBTJNyhy9cK5g@mail.gmail.com>
In-Reply-To: 
 <CA+K2Rum-TB_iNzDWoXOJspf=jq0gd-wees8+9tBTJNyhy9cK5g@mail.gmail.com>
From: KAZAR Ayoub <ma_kazar@esi.dz>
Date: Wed, 18 Mar 2026 03:29:32 +0100
Message-ID: 
 <CA+K2Ru=PdZuXQbcfvqKysTkebTyXNd9j7dp+mTFQEYpLdGw1eA@mail.gmail.com>
Subject: Re: Speed up COPY TO text/CSV parsing using SIMD
To: Nathan Bossart <nathandbossart@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
 Pg Hackers <pgsql-hackers@postgresql.org>,
	Neil Conway <neil.conway@gmail.com>,
 Manni Wood <manni.wood@enterprisedb.com>,
	Andrew Dunstan <andrew@dunslane.net>, Shinya Kato <shinya11.kato@gmail.com>,
	Mark Wong <markwkm@gmail.com>, Nazir Bilal Yavuz <byavuz81@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000008e5652064d433988"
Archived-At: 
 <https://www.postgresql.org/message-id/CA%2BK2Ru%3DPdZuXQbcfvqKysTkebTyXNd9j7dp%2BmTFQEYpLdGw1eA%40mail.gmail.com>
Precedence: bulk

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

On Wed, Mar 18, 2026 at 12:02=E2=80=AFAM KAZAR Ayoub <ma_kazar@esi.dz> wrot=
e:

> On Tue, Mar 17, 2026 at 7:49=E2=80=AFPM Nathan Bossart <nathandbossart@gm=
ail.com>
> wrote:
>
>> On Sat, Mar 14, 2026 at 11:43:38PM +0100, KAZAR Ayoub wrote:
>> > Just a small concern about where some varlenas have a larger binary si=
ze
>> > than its text representation ex:
>> > SELECT pg_column_size(to_tsvector('SIMD is GOOD'));
>> >  pg_column_size
>> > ----------------
>> >              32
>> >
>> > its text representation is less than sizeof(Vector8) so currently v3
>> would
>> > enter SIMD path and exit out just from the beginning (two extra
>> branches)
>> > because it does this:
>> > + if (TupleDescAttr(tup_desc, attnum - 1)->attlen =3D=3D -1 &&
>> > + VARSIZE_ANY_EXHDR(DatumGetPointer(value)) > sizeof(Vector8))
>> >
>> > I thought maybe we could do * 2 or * 4 its binary size, depends on the
>> type
>> > really but this is just a proposition if this case is something
>> concerning.
>>
>> Can we measure the impact of this?  How likely is this case?
>>
> I'll respond to this separately in a different email.
>
My example was already incorrect (the text representation is lexems and
positions, not the text we read as it is, its lossy), anyways the point
still holds.
If we have some json(b) column like : {"key1":"val1","key2":"val2"}, for
CSV format this would immediately exit the SIMD path because of quote
character, for json(b) this is going to be always the case.
I measured the overhead of exiting the SIMD path a lot (8 million times for
one COPY TO command), i only found 3% regression for this case, sometimes
2%.

For cases where we do a false commitment on SIMD because we read a binary
size >=3D sizeof(Vector8), which i found very niche too, the short circuit =
to
scalar each time is even more negligible (the above CSV JSON case is the
absolute worst case).
So I don't think any of this should be a concern.


Regards,
Ayoub

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

<div dir=3D"ltr"><div dir=3D"ltr">On Wed, Mar 18, 2026 at 12:02=E2=80=AFAM =
KAZAR Ayoub &lt;<a href=3D"mailto:ma_kazar@esi.dz">ma_kazar@esi.dz</a>&gt; =
wrote:<br></div><div class=3D"gmail_quote gmail_quote_container"><blockquot=
e class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px s=
olid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><=
div dir=3D"ltr">On Tue, Mar 17, 2026 at 7:49=E2=80=AFPM Nathan Bossart &lt;=
<a href=3D"mailto:nathandbossart@gmail.com" target=3D"_blank">nathandbossar=
t@gmail.com</a>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex">On Sat, Mar 14, 2026 at 11:43:38PM +0=
100, KAZAR Ayoub wrote:<br>
&gt; Just a small concern about where some varlenas have a larger binary si=
ze<br>
&gt; than its text representation ex:<br>
&gt; SELECT pg_column_size(to_tsvector(&#39;SIMD is GOOD&#39;));<br>
&gt;=C2=A0 pg_column_size<br>
&gt; ----------------<br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 32<br>
&gt; <br>
&gt; its text representation is less than sizeof(Vector8) so currently v3 w=
ould<br>
&gt; enter SIMD path and exit out just from the beginning (two extra branch=
es)<br>
&gt; because it does this:<br>
&gt; + if (TupleDescAttr(tup_desc, attnum - 1)-&gt;attlen =3D=3D -1 &amp;&a=
mp;<br>
&gt; + VARSIZE_ANY_EXHDR(DatumGetPointer(value)) &gt; sizeof(Vector8))<br>
&gt; <br>
&gt; I thought maybe we could do * 2 or * 4 its binary size, depends on the=
 type<br>
&gt; really but this is just a proposition if this case is something concer=
ning.<br>
<br>
Can we measure the impact of this?=C2=A0 How likely is this case?<br></bloc=
kquote><div>I&#39;ll respond to this separately=C2=A0in a different email.<=
/div></div></div></div></blockquote><div>My example was already incorrect (=
the text representation is lexems=C2=A0and positions, not the text we read =
as it is, its lossy), anyways the point still holds.</div><div>If we have s=
ome json(b) column like :=C2=A0{&quot;key1&quot;:&quot;val1&quot;,&quot;key=
2&quot;:&quot;val2&quot;}, for CSV format this would immediately exit the S=
IMD path because of quote character, for json(b) this is going to be always=
 the case.</div><div>I measured=C2=A0the overhead of exiting=C2=A0the SIMD =
path a lot (8 million times for one COPY TO command), i only found 3% regre=
ssion for this case, sometimes 2%.</div><div><br></div><div>For cases where=
 we do a false commitment on SIMD because we read a binary size &gt;=3D siz=
eof(Vector8), which i found very niche too, the=C2=A0short circuit to scala=
r each time is even more negligible (the above CSV JSON case is the absolut=
e worst case).</div><div>So I don&#39;t think any of this should be a conce=
rn.</div><div><br></div><div><br></div><div>Regards,</div><div>Ayoub</div><=
/div></div>

--0000000000008e5652064d433988--