From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | John Naylor <jcnaylor(at)gmail(dot)com>, Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Speeding up text_position_next with multibyte encodings |
Date: | 2019-01-25 14:33:54 |
Message-ID: | b65df3d8-1f59-3bd7-ebbe-68b81d5a76a4@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 15/01/2019 02:52, John Naylor wrote:
> The majority of cases are measurably faster, and the best case is at
> least 20x faster. On the whole I'd say this patch is a performance win
> even without further optimization. I'm marking it ready for committer.
I read through the patch one more time, tweaked the comments a little
bit, and committed. Thanks for the review!
I did a little profiling of the worst case, where this is slower than
the old approach. There's a lot of function call overhead coming from
walking the string with pg_mblen(). That could be improved. If we
inlined pg_mblen() into loop, it becomes much faster, and I think this
code would be faster even in the worst case. (Except for the very worst
cases, where hash table with the new code happens to have a collision at
a different point than before, but that doesn't seem like a fair
comparison.)
I think this is good enough as it is, but if I have the time, I'm going
to try optimizing the pg_mblen() loop, as well as similar loops e.g. in
pg_mbstrlen(). Or if someone else wants to give that a go, feel free.
- Heikki
From | Date | Subject | |
---|---|---|---|
Next Message | Chapman Flack | 2019-01-25 14:37:35 | Re: House style for DocBook documentation? |
Previous Message | Petr Jelinek | 2019-01-25 14:26:55 | Re: [HACKERS] logical decoding of two-phase transactions |