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