Date: Wed, 23 Sep 2026 12:09:08 -0500
From: Nathan Bossart <nathandbossart@gmail.com>
To: Sehrope Sarkuni <sehrope@jackdb.com>
Cc: Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Speed up lpad() and rpad() for one-byte padding strings
Message-ID: <arQHtMApsI6MX-XH@nathan>
References: 
 <CAH7T-apj+pFg9bRkXVGfGejS2Uu4WzdMd7KoLKTW11mdsrt1Ew@mail.gmail.com>
 <arPlICNzFXv6zTbS@nathan>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="7fFRVEp6g7hhzb9Y"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <arPlICNzFXv6zTbS@nathan>
Archived-At: <https://www.postgresql.org/message-id/arQHtMApsI6MX-XH%40nathan>
Precedence: bulk

--7fFRVEp6g7hhzb9Y
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline

On Wed, Sep 23, 2026 at 09:41:36AM -0500, Nathan Bossart wrote:
> On Wed, Sep 23, 2026 at 10:10:09AM -0400, Sehrope Sarkuni wrote:
>> lpad() and rpad() pad one character at a time, calling
>> pg_mblen_range() and memcpy() once per padding char.  When the padding
>> string is a single byte, e.g., lpad(x, n, '0') or rpad(x, n, ' '),
>> the padding is that byte repeated, so the attached patch fills it with
>> one memset().
> 
> I wonder if we could expand these gains by using SIMD whenever the vector
> length is divisible by the padding string length.  My hunch is that's where
> a lot of the memset() gains come from.

Actually, I think we can expand this to any padding string length by
copying the padding string once, and then copying from the beginning of the
padding to the end repeatedly so that we write double the padding each
time.  This is a bit like what commit c60e520 added for pglz_decompress().
I've attached some proof-of-concept grade patches.  This doesn't quite
match the performance of your 1-byte fast-path, but it's pretty close and
applies to many more cases.

-- 
nathan

--7fFRVEp6g7hhzb9Y
Content-Type: text/plain; charset=us-ascii
Content-Disposition: attachment;
	filename=v2-0001-Factor-the-padding-loop-out-of-lpad-and-rpad.patch