Skip site navigation (1) Skip section navigation (2)

Re: [HACKERS] like/ilike improvements

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: ITAGAKI Takahiro <itagaki(dot)takahiro(at)oss(dot)ntt(dot)co(dot)jp>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>
Subject: Re: [HACKERS] like/ilike improvements
Date: 2007-06-01 22:58:18
Message-ID: 25310.1180738698@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> ITAGAKI Takahiro wrote:
>>         | SQL_ASCII | LATIN1 |  UTF8 | EUC_JP 
>> ---------+-----------+--------+-------+---------
>> HEAD    |      8017 |   8029 | 16928 |  18213 
>> Patched |      7899 |   7887 |  9985 |  10370 [ms]
>> 
>> It improved the performance not only for UTF8, but also for other
>> multi-byte encodings and a bit for single-byte encodings.

> Interesting. I infer from these results that the biggest bang here comes 
> from abandoning CHAREQ and doing all comparisons byte-wise.

It looks like CHAREQ and NextChar are both pretty expensive, no doubt
due to having to drill down through the MB encoding vectoring mechanism
to find out what to do.

A technique we might want to apply in future patches is to have an API
whereby we can get a direct function pointer to the appropriate mblen
or other encoding-dependent function, and then call directly to the
right place in the inner loops instead of having to go through the
intermediate vectoring function every time.

			regards, tom lane

In response to

pgsql-hackers by date

Next:From: Jim NasbyDate: 2007-06-01 23:42:24
Subject: Re: Ye olde drop-the-database-you-just-left problem
Previous:From: Tom LaneDate: 2007-06-01 22:54:04
Subject: Re: [HACKERS] like/ilike improvements

pgsql-patches by date

Next:From: Andrew DunstanDate: 2007-06-02 02:05:32
Subject: Re: [HACKERS] like/ilike improvements
Previous:From: Tom LaneDate: 2007-06-01 22:54:04
Subject: Re: [HACKERS] like/ilike improvements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group