| From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp>, phede-ml(at)islande(dot)org, pgsql-hackers(at)postgresql(dot)org |
| Subject: | Re: Unicode combining characters |
| Date: | 2001-10-02 17:55:47 |
| Message-ID: | 200110021755.f92HtlH19729@candle.pha.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> writes:
> > If no one can find a case where multibyte is slower, I think we should
> > enable it by default. Comments?
>
> Well, he just did point out such a case:
>
> >> no MB with MB
> >> LIKE 0.09 msec 0.08 msec
> >> REGEX 0.09 msec 0.10 msec
>
> But I agree with your conclusion. If the worst penalty we can find is
> that a regex comparison operator is 10% slower, we may as well turn it
> on by default. Most people will never notice the difference, and anyone
> who really cares can always turn it off again.
But the strange thing is that LIKE is faster, perhaps meaning his
measurements can't even see the difference, or is it because the LIKE
optimization is off for multibyte.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Marc G. Fournier | 2001-10-02 18:02:13 | Re: do we're in time to catch 7.2 Beta ? |
| Previous Message | Bruce Momjian | 2001-10-02 17:53:28 | Re: do we're in time to catch 7.2 Beta ? |