Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
10.8.1.2, 10.8.2.2
-
None
-
Normal
-
Repro attached
-
Performance, Seen in production
Description
Sounds incrediable? Test it by yourself with the attached program.
The issued reased up because of AMQ-3644, but it is actually a derby problem so I post the issue here as well.
Derby writes multiple gigabyte of temporary files in its tmp directory during one select statement. Afterwards these temporary files are deleted and rebuild by the next Statement.
You can find a Test-Program (import it as a Maven-Eclipse project) which reproduces this issue.
This program creates a derby database with the activemq Message table and fills it with data (2000 Messages, this can take several hours). I assumed 3MB for one message as our messages contain same binary data and has an average size of 3MB.
After the database is built one time a Statement and another time a PreparedStatment is used to retrieve the next messages.
The Statement takes about 1 ms and the PreparedStatement about 258805 ms. Also the second PreparedStatement takes as much time.
Attachments
Attachments
Issue Links
- relates to
-
DERBY-3753 select from table with integer primary key and blob column does not do sort avoidance
- Open