Re: Unicode database + JDBC driver performance

On Sat, Dec 21, 2002 at 03:33:57PM -0500, Tom Lane wrote:
> If no translation is happening then I can't see a reason for any
> difference at all, given what you were doing.
>
> I can imagine speed differences for operations that actually interpret
> the character data --- for example, sorting on a text column --- but
> AFAICT you weren't doing anything like that.
>
> It'd be worth checking first to see whether the extra time is really
> being spent in the backend, client, or both.

Hello,

Here are the results of the more detailed benchmarks.

Legend: the left column is "utime", right column is "stime" (both in
jiffies) according to "cat /proc/<pid>/stat" output for the 'postgres'
process created by establishing the database connection. For the client,
I used the Unix 'time' command (and assumed 1 jiffie == 1/100s).

In short, we can see that the backend's performance is somewhat worse
for the Unicode database in the INSERT benchmark. The client's
(driver's) performance is much worse for Unicode in this same
benchmark.

In the SELECT benchmark, the backend performance does not vary
between UNICODE and LATIN1 (nice!). The difference in client's
performance is even bigger than in the INSERT benchmark, though.

It looks like the driver needs some profiling to find out the reason.

Thanks for your assistance.

-JPL

INSERT benchmark

backend
LATIN1 UNICODE
351 102 480 134
370 112 476 164
376 126 496 178
359 125 498 126
------- -------
364 116 487 150 33% 29% worse

client
LATIN1 UNICODE
234 45 418 56
224 56 441 48
241 43 430 49
222 41 439 34
------- -------
230 46 432 47 87% 2% worse

SELECT benchmark

backend
LATIN1 UNICODE
70 9 74 15
74 19 84 14
84 12 71 11
71 13 74 14
----- -----
75 13 76 14 about the same

client
LATIN1 UNICODE
217 22 529 14
217 18 544 25
217 26 534 14
219 21 542 17
------- -------
218 22 537 18 146% worse