| From: | Sehrope Sarkuni <sehrope(at)jackdb(dot)com> |
|---|---|
| To: | Nathan Bossart <nathandbossart(at)gmail(dot)com> |
| Cc: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Speed up lpad() and rpad() for one-byte padding strings |
| Date: | 2026-09-23 17:19:51 |
| Message-ID: | CAH7T-apA=BmTS7=JdLWGMLVsMZ=T=hL3amn6EESFyywR=dt2hA@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 23, 2026 at 1:09 PM Nathan Bossart <nathandbossart(at)gmail(dot)com> wrote:
>
> 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.
Ah! just saw this after I hit send.
I think my version does the rest of what you're describing!
Exact conclusion reached from testing it too.
Regards,
-- Sehrope Sarkuni
Founder & CEO | JackDB, Inc. | https://www.jackdb.com/
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sami Imseih | 2026-09-23 17:21:46 | Re: Add REPACK progress phases for logical decoding setup |
| Previous Message | Thom Brown | 2026-09-23 17:18:20 | Re: REPACK (CONCURRENTLY) can silently lose updates when the toast table is rewritten |