Re: [HACKERS] Implications of multi-byte support in a distribution

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

Responses

Browse pgsql-hackers by date

  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