Re: Optimizing COPY with SIMD - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Optimizing COPY with SIMD
Date
Msg-id ZmC28LZUXg3URgWX@nathan
Whole thread Raw
In response to Re: Optimizing COPY with SIMD  (Neil Conway <neil.conway@gmail.com>)
Responses Re: Optimizing COPY with SIMD
List pgsql-hackers
On Wed, Jun 05, 2024 at 01:46:44PM -0400, Neil Conway wrote:
> We could go further and use the same code to handle both the tail of the
> string in the vectorized case and the entire string in the non-vectorized
> case, but I didn't bother with that -- as written, it would require taking
> an unnecessary strlen() of the input string in the non-vectorized case.

For pg_lfind32(), we ended up using an overlapping approach for the
vectorized case (see commit 7644a73).  That appeared to help more than it
harmed in the many (admittedly branch predictor friendly) tests I ran.  I
wonder if you could do something similar here.

> Looks like there is a slight regression for short attribute values, but I
> think the tradeoff is a net win.

It'd be interesting to see the threshold where your patch starts winning.
IIUC the vector stuff won't take effect until there are 16 bytes to
process.  If we don't expect attributes to ordinarily be >= 16 bytes, it
might be worth trying to mitigate this ~3% regression.  Maybe we can find
some other small gains elsewhere to offset it.

-- 
nathan



pgsql-hackers by date:

Previous
From: Andrew Dunstan
Date:
Subject: Re: ssl tests fail due to TCP port conflict
Next
From: Nathan Bossart
Date:
Subject: Re: Better error message when --single is not the first arg to postgres executable