Re: client libpq multibyte support

Please allow me to pick out this thread again.

> > True, and in fact most of the performance problem in the client-side
> > MULTIBYTE code comes from the fact that it's not designed-in, but tries
> > to be a minimally intrusive patch. I think we could make it go faster
> > if we accepted that it was standard functionality. So I'm not averse to
> > going in that direction in the long term ...

I have checked the performance problem.

(Environment)
- Hardware : P200pro CPU, 128MB, 5400rpm disk
- OS : Red hat Linux-5.2
- Database version : postgresql-7.0RC1

(Tested software and data)
- Library : libpq
- Program : ecpg application program, psql
- SQL : insert, select
- Number of tuples : 100,000 tuples

(Test case)
(1) non-MULTIBYTE
(2) MULTIBYTE encoding=SQL_ASCII

An ecpg program and the psql were used in this test case.

(Result)
As for the result, there was no difference in the speed of (1)
and (2). I could *not* find the performance problem.

(Improvement)
However, the performance problem may occur if the test of
10,000,000 tuples will be done. Because PQmblen() has a little
overhead of routine-call. Therefore, if the MULTIBYTE PQmblen()
will be changed as the following, the perfomance problem disappers
*perfectly*.

# ifdef MULTIBYTE
int PQmblen(const unsigned char *s, int encoding){
if( encoding == SQL_ASCII ) return 1; <======= Added line
return (pg_encoding_mblen(encoding, s));
}
# endif

(Conclusion)
A client library/application should be made by "configure
--enable-multibyte[=SQL_ASCII]" when postgresql is made by
"configure [non-MULTIBYTE]".

(Reference of library size)
non-MULTIBYTE MULTIBYTE
libpq.a 69KB 91KB
libpq.so.2.0 52KB 52KB
libpq.so.2.1 60KB 78KB

--
Regard,
SAKAIDA Masaaki -- Osaka, Japan