From: Alexander Borisov <lex.borisov@gmail.com>
To: Jeff Davis <pgsql@j-davis.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
To: pgsql-hackers@postgresql.org
Subject: Re: Optimization for lower(), upper(), casefold() functions.
Date: Wed, 19 Feb 2025 01:54:35 +0300
Message-ID: <e9057c71-93ec-4a21-b02e-979c7da2b665@gmail.com> (raw)
In-Reply-To: <d0dd50662da84f582c34247f4ed43061e8d86d34.camel@j-davis.com>
References: <7cac7e66-9a3b-4e3f-a997-42aa0c401f80@gmail.com>
<2a1b632e-4531-43cf-a6d9-51cc1a271dc1@gmail.com>
<e7abe9be-1f1a-4fed-9cc3-35be257bab34@gmail.com>
<7ab9d255-d7c0-4841-96c3-ed3ce9aa4abd@iki.fi>
<12956299-1496-4455-b3ab-299cc0a87d7c@gmail.com>
<340f2451-cd76-487b-a1e4-0f0a2fe91fba@gmail.com>
<3ffb8b75b26e76624668c0883cac7886468c5d07.camel@j-davis.com>
<5cf176fa-44b9-4019-b9b7-ee902352a844@gmail.com>
<3080de9bcce916cf8720ac197f634e381c4de564.camel@j-davis.com>
<1e3f4f6f-9b12-4109-b0d2-a4c52b5064f8@gmail.com>
<d0dd50662da84f582c34247f4ed43061e8d86d34.camel@j-davis.com>
19.02.2025 01:02, Jeff Davis пишет:
> On Tue, 2025-02-11 at 23:08 +0300, Alexander Borisov wrote:
>> I tried the approach via a range table. The result was worse than
>> without the table. With branching in a function, the result is
>> better.
>>
>> Patch v3 — ranges binary search by branches.
>> Patch v4 — ranges binary search by table.
>
> Thoughts on v3:
>
> It looks like the top 5 bits of the offset are unused. What if we used
> those bits for flags to indicate:
>
> HAS_LOWER
> HAS_UPPER
> HAS_FOLD
> HAS_SPECIAL
> HAS_TITLE
>
> That way, we only need to look in the corresponding table if it
> actually has an entry other than the codepoint itself.
>
> It doesn't leave a lot of room if the tables get larger, but if we are
> worried about that, we could eliminate HAS_TITLE, because I don't think
> the performance for INITCAP() is as important as LOWER/UPPER/CASEFOLD.
>
> Regards,
> Jeff Davis
>
It seems to be micro-optimizations. In the sense that the code is very
clear and understandable now.
These micro-optimizations make the code more complex, and there will be
no performance gain.
In proposing the patch for v3, I struck a balance between improving
performance and reducing binary size, without sacrificing code clarity.
We can go into micro-optimizations now and lose the essence of
the proposed improvements. And ahead of us we have
Unicode Normalization Forms.
I'm willing to try different approaches, but there's confidence that
we've found a great optimization right now.
--
Alexander Borisov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: lex.borisov@gmail.com, pgsql@j-davis.com, hlinnaka@iki.fi
Subject: Re: Optimization for lower(), upper(), casefold() functions.
In-Reply-To: <e9057c71-93ec-4a21-b02e-979c7da2b665@gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox