picoSQL benchmark

Doing a comparison between various database management systems is a very delicate task. There are so many factors to take in consideration, beginning with the hardware configuration till ending with choosing the queries type. For this reason we do not publish comparisons but we give only some indications and we put to disposition of sources for who wishes to make comparisons his own. If someone wish to compare picoSQL with other databases, we'll be happy to publish the results. the following
The first aspect we have estimated regards costancy of the performance to growing of the concurrency of the accesses. The costancy of the performances of a database is an important data that it serves to guarantee that the programs that we are developing today, typically with little data to disposition and accessed by few persons, works tomorrow also when the database is filled and the accesses grown.

In order to make of the concurrency tests, we have used the Java multithreading capability. The JavaConcBench.java program creates a table with three attributes, two numerical ones and textual the third. Two unique indices are created on the first numerical attribute and on the textual attribute. The program inserts the first row with the values "(0, 0, ' First record ')". To this point the program generates some thread, whose number is specified on the command line. Each thread writes a row identified by the name that Java assigns to every thread. Each thread begins therefore a cycle in which it read the first row of the DB with "select... for update" to lock the row (the "SuspensiveLock" option must be set to YES). The value of the first attribute is increased by 1 and the row is rewritten.Then it is rewritten the characteristic row of the thread putting in the first attribute the just read number and in the second attribute the count of number of operation. All the thread approach therefore a same row, so simulating one condition of elevated concurrency. The correctness of the concurrency is guaranteed by the fact that the first attribute in the table, which is bind to a unique index, does not join duplicated in any moment. The program finishes after 10'000 operations executed from all the thread. Increasing the number of thread therefore the number of operations does not change and therefore the optimal result is had when the program employs the same time launched with a number whichever of thread.
In the tests made on the computer on which we executed the test (Linux Pentium4 1.9Ghz) the program using picoSQL takes 57 second when launched with only 1 thread. The time increases to 1 minute and 8 second when the contemporary threads are 16, and it increases to 1 minute and 19 seconds when the contemporary threads are 128. The same program running with Oracle 8.1.7.0.1 RDBMS, installed on the same computer without particular configuration options, takes 1 minute and 12 seconds if launched with 1 thread and 3 minutes if launched with 16 thread. We made no test with 128 thread because to do that we need to reconfigure the computer. We also tried to make this test with other RDBM, MS-SQL and mySQL, but we were not able to do that, probably because we do not know that systems very well.