From: Jehan-Guillaume de Rorthais <jgdr@dalibo.com>
To: Thomas Munro <thomas.munro@gmail.com>
To: Peter Geoghegan <pg@bowt.ie>
Cc: Роман Литовченко <roman.lytovchenko@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Subject: Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows
Date: Fri, 12 Jun 2020 18:40:55 +0200
Message-ID: <20200612184055.205f0159@firost> (raw)
In-Reply-To: <20200610002933.6a6d482b@firost>
References: <153201618542.1404.3611626898935613264@wrigleys.postgresql.org>
<CAH2-Wz=TGN_03qBmqgFXVhw6Kbfys-EBz4MJunzRq+RB5gL7WA@mail.gmail.com>
<CAH2-Wzkiue6PQzneBJsuDnYdUVMa5jnevVJXXkV3hR0oboOSbQ@mail.gmail.com>
<CAEepm=1-f3OuO_zA83C0x8dLFqMA+Q=RGUkyMRp4WXxjSrvbww@mail.gmail.com>
<20200610002933.6a6d482b@firost>
On Wed, 10 Jun 2020 00:29:33 +0200
Jehan-Guillaume de Rorthais <jgdr@dalibo.com> wrote:
[...]
> After playing with ICU regression tests, I found functions ucol_strcollIter
> and ucol_nextSortKeyPart are safe. I'll do some performance tests and report
> here.
I did some benchmarks. See attachment for the script and its header to
reproduce.
It sorts 935895 french phrases from 0 to 122 chars with an average of 49.
Performance tests were done on current master HEAD (buggy) and using the patch
in attachment, relying on ucol_strcollIter.
My preliminary test with ucol_getSortKey was catastrophic, as we might
expect. 15-17x slower than the current HEAD. So I removed it from actual tests.
I didn't try with ucol_nextSortKeyPart though.
Using ucol_strcollIter performs ~20% slower than HEAD on UTF8 databases, but
this might be acceptable. Here are the numbers:
DB Encoding HEAD strcollIter ratio
UTF8 2.74 3.27 1.19x
LATIN1 5.34 5.40 1.01x
I plan to add a regression test soon.
> In the meantime, I've been working on various workarounds. The only one I
> found is to use "fr-u-kr-latn-digit-kn" instead of "fr-u-kr-latn-digit".
> Unfortunately, the two collations are not equivalent, but I believe it might
> be useful in many case.
>
> I've been working on a second workaround: creating a type (a char variant for
> our usecase), its operators and opfamily. All operators and function 1 relies
> on ucol_getSortKey. Most of the workaround works good but surprisingly, the
> sort order is only enforced if the field is in the first position:
>
> * this works: "SORT BY f1 COLLATE digitslast"
> * this fails: "SORT BY f2, f1 COLLATE digitslast"
I fixed this. I didn't declare my opclass as default for the type I created.
I'm not sure people would like to see/discuss this user workaround here?
Regards,
Attachments:
test-icu.bash (application/octet-stream, 1.3K) download
v1-0001-Replace-buggy-ucol_strcoll-funcs-with-ucol_strcollIt.patch (text/x-patch, 0B) download
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-bugs@postgresql.org
Cc: jgdr@dalibo.com, thomas.munro@gmail.com, pg@bowt.ie, roman.lytovchenko@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15285: Query used index over field with ICU collation in some cases wrongly return 0 rows
In-Reply-To: <20200612184055.205f0159@firost>
* 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