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
