I did some benchmarking with/without multibyte support using current.

(1) regression test

With multibyte support:
9.52user 3.38system 0:59.27elapsed 21%CPU (0avgtext+0avgdata  0maxresident)k

Without multibyte support:
8.97user 4.84system 1:00.85elapsed 22%CPU (0avgtext+0avgdata  0maxresident)k

(2) pgbench

With multibyte support(first column is the concurrent user, second is
the TPS):

1 46.004932
2 70.848123
4 88.147471
8 90.472970
16 96.620166
32 95.947363
64 92.718780
128 61.725883

Witout multibyte support:
1 52.668169
2 68.132654
4 79.956663
8 81.133516
16 96.618124
32 92.283645
64 86.936559
128 87.584099

for your convenience, a graph is attached(bench.png).

(3) testing environment

Linux kernel 2.2.17
PIII 750MHz, 256MB RAM, IDE disk
configure option: configure --enable-multibyte=EUC_JP or configure
postgresql.conf settings(other than default):
		max_connections = 128
		shared_buffers = 1024
		wal_sync_method = open_sync
		deadlock_timeout = 100000
pgbench options:
	-s 2 (initialization)
	-t 10 (benchmarking)
--
Tatsuo Ishii
Thu, 27 Sep 2001 14:22:07 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
multibyte performance
Tatsuo Ishii wrote:
> 
> I did some benchmarking with/without multibyte support using current.

...
 
> (2) pgbench
> 
> With multibyte support(first column is the concurrent user, second is
> the TPS):
...
> 32 95.947363
> 64 92.718780
> 128 61.725883
> 
> Witout multibyte support:
...
> 32 92.283645
> 64 86.936559
> 128 87.584099

Do you have any theory why multibyte passes non-mb at 128 ?

Some subtle timing thing perhaps (or just bad luck for non-mb at 128)?


-----------
Hannu

Thu, 27 Sep 2001 13:00:41 +0500
Hannu Krosing <hannu@tm.ee>
Re: multibyte performance
On Thu, Sep 27, 2001 at 02:22:07PM +0900, Tatsuo Ishii wrote:
> I did some benchmarking with/without multibyte support using current.
> 
> (1) regression test
> 
> With multibyte support:
> 9.52user 3.38system 0:59.27elapsed 21%CPU (0avgtext+0avgdata  0maxresident)k
> 
> Without multibyte support:
> 8.97user 4.84system 1:00.85elapsed 22%CPU (0avgtext+0avgdata  0maxresident)k

 It's nice.

 Can you try it for old 7.1? I should like see some improvement between
release:-)

	Karel

-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz

Thu, 27 Sep 2001 10:56:04 +0200
Karel Zak <zakkr@zf.jcu.cz>
Re: multibyte performance
>  It's nice.

:-)

>  Can you try it for old 7.1? I should like see some improvement between
> release:-)

Not sure if it's meaningfull since new regression test cases might be
added for current?
--
Tatsuo Ishii

Thu, 27 Sep 2001 18:19:32 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: multibyte performance
> > With multibyte support(first column is the concurrent user, second is
> > the TPS):
> ...
> > 32 95.947363
> > 64 92.718780
> > 128 61.725883
> > 
> > Witout multibyte support:
> ...
> > 32 92.283645
> > 64 86.936559
> > 128 87.584099
> 
> Do you have any theory why multibyte passes non-mb at 128 ?
> 
> Some subtle timing thing perhaps (or just bad luck for non-mb at 128)?

May be or may not be. I was anxious about the load module size and
thought it might stress the memory. So while running pgbench I checked
the memory usage using vmstat. However it showed no excess page
in/page out...
--
Tatsuo Ishii

Thu, 27 Sep 2001 21:30:38 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: multibyte performance
Tatsuo Ishii <t-ishii@sra.co.jp> writes:
> I did some benchmarking with/without multibyte support using current.
> (1) regression test
> (2) pgbench

pgbench unfortunately seems quite irrelevant to this issue, since it
performs no textual operations whatsoever.  It'd be interesting to
modify pgbench so that it updates the "filler" column somehow on each
update (perhaps store a text copy of the new balance there), and then
repeat the tests.

			regards, tom lane

Thu, 27 Sep 2001 10:09:13 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: multibyte performance 
> pgbench unfortunately seems quite irrelevant to this issue, since it
> performs no textual operations whatsoever.

Yup.

>  It'd be interesting to
> modify pgbench so that it updates the "filler" column somehow on each
> update (perhaps store a text copy of the new balance there), and then
> repeat the tests.

Maybe. I'm not sure if it would show significant differences though.

Anyway, what I'm interested in include:

o regexp/like/ilike operations
o very long text handling

I'll come up with more testings..
--
Tatsuo Ishii

Fri, 28 Sep 2001 10:05:24 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: multibyte performance 
> > I did some benchmarking with/without multibyte support using current.
> > (1) regression test
> > (2) pgbench
> 
> pgbench unfortunately seems quite irrelevant to this issue, since it
> performs no textual operations whatsoever.  It'd be interesting to
> modify pgbench so that it updates the "filler" column somehow on each
> update (perhaps store a text copy of the new balance there), and then
> repeat the tests.

Ok. Here is the result:

Without multibyte:
1 50.190473
2 65.943052
4 74.908752
8 62.589973
16 87.546988
32 94.448773
64 88.019452
128 64.107839

With multibyte:
1 47.473237
2 61.435628
4 83.047684
8 95.556846
16 92.157352
32 95.879001
64 91.486652
128 66.926568

a graph is attached.
Fri, 28 Sep 2001 15:27:22 +0900
Tatsuo Ishii <t-ishii@sra.co.jp>
Re: multibyte performance 