From: | Tatsuo Ishii <t-ishii(at)sra(dot)co(dot)jp> |
---|---|
To: | Thomas Lockhart <lockhart(at)alumni(dot)caltech(dot)edu> |
Cc: | Oliver Elphick <olly(at)lfix(dot)co(dot)uk>, hackers(at)postgreSQL(dot)org, 43702(at)bugs(dot)debian(dot)org |
Subject: | Re: [HACKERS] Implications of multi-byte support in a distribution |
Date: | 1999-08-31 09:29:21 |
Message-ID: | 199908310929.SAA29273@srapc451.sra.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I have had a request to add multi-byte support to the Debian binary
>> packages of PostgreSQL.
>> Since I live in England, I have personally no need of this and therefore
>> have little understanding of the implications.
>> If I change the packages to use multi-byte support, (UNICODE (UTF-8) is
>> suggested as the default), will there be any detrimental effects on the
>> fairly large parts of the world that don't need it? Should I try to
>> provide two different packages, one with and one without MB support?
>
>Probably. The downside to having MB support is reduced performance and
>perhaps functionality. If you don't need it, don't build it...
Not really. I did the regression test with/without multi-byte enabled.
with MB: 2:53:92 elapsed
w/o MB: 2:52.92 elapsed
Perhaps the worst case for MB would be regex ops. If you do a lot of
regex queries, performance degration might not be neglectable.
Load module size:
with MB: 1208542
w/o MB: 1190925
(difference is 17KB)
Talking about the functionality, I don't see any missing feature with
MB comparing w/o MB. (there are some features only MB has. for
example, SET NAMES).
--
Tatsuo Ishii
From | Date | Subject | |
---|---|---|---|
Next Message | Oleg Bartunov | 1999-08-31 11:56:34 | Re: [HACKERS] Implications of multi-byte support in a distribution |
Previous Message | yutaka tanida | 1999-08-31 08:38:59 | Re: IPC on win32 - additions for 6.5.2 and current trees |