Hello devlist,

A couple of weeks ago there was a small discussion on the list about
postgresql 7.3 and mmbase. The newest driver from postgresql threw errors
about oidin when a byte field was inserted. I managed to get this thing to
run, but the mapping for the byte field should be to bytea with the newest
driver and not OID. After I changed to bytea I got OutOfMemory problems with
images larger than 1mb. I had to set the memory usage to -Xmx256m to insert
a 4mb image which is the default uploadsize of the editwizards.

After I had to do that, I did some test on both byte types in postgresql
(oid and bytea). I start to dislike the bytea field for 2 reasons. 1 it eats
memory whithout a good reason and 2 it is very slow compared to its
counterpart.

Some results of my test

[bytea] storing    0k of data -> 180ms
[bytea] retrieving 0k of data -> 21ms
[LO/oid] storing    0k of data -> 451ms
[LO/oid] retrieving 0k of data -> 170ms
[bytea] storing    1k of data -> 41ms
[bytea] retrieving 1k of data -> 10ms
[LO/oid] storing    1k of data -> 20ms
[LO/oid] retrieving 1k of data -> 30ms
[bytea] storing    500k of data -> 643ms
[bytea] retrieving 500k of data -> 642ms
[LO/oid] storing    500k of data -> 120ms
[LO/oid] retrieving 500k of data -> 391ms
[bytea] storing    1000k of data -> 1174ms
[bytea] retrieving 1000k of data -> 1174ms
[LO/oid] storing    1000k of data -> 241ms
[LO/oid] retrieving 1000k of data -> 471ms
[bytea] storing    4000k of data -> 19123ms
[bytea] retrieving 4000k of data -> 5659ms
[LO/oid] storing    4000k of data -> 1746ms
[LO/oid] retrieving 4000k of data -> 1665ms

Actually, the oid is to slow here, because the jvm is recovering from the
memory consumption of the bytea field
Here the result without the bytea. I could even run this test without the
memory setting to 256m (default is 64m)

[LO/oid] storing    0k of data -> 70ms
[LO/oid] retrieving 0k of data -> 100ms
[LO/oid] storing    1k of data -> 21ms
[LO/oid] retrieving 1k of data -> 60ms
[LO/oid] storing    500k of data -> 121ms
[LO/oid] retrieving 500k of data -> 341ms
[LO/oid] storing    1000k of data -> 220ms
[LO/oid] retrieving 1000k of data -> 592ms
[LO/oid] storing    4000k of data -> 692ms
[LO/oid] retrieving 4000k of data -> 1023ms

[LO/oid] storing    63999k of data -> 10972ms
[LO/oid] retrieving 63999k of data -> 14545ms

Inserting 16m in a bytea field took ages and the memory had to be set to
1024m.

Retrieving the byte fields from the database will always require a least the
size of the blob, but that does not explain why the bytea field requires so
much memory.
The disadvantage of the oid is that it uses a postgres api to get it in
stead of the standard java.sql api.

Which byte field for postgresql are we going to support in the next releases
of mmbase? I prefer the oid, but this will require the postgresql driver
when building mmbase for postgresq.

Nico Klasens

Finalist IT Group
Java Specialists



Attachment: BLOBTest.java
Description: Binary data

Reply via email to