Hi Jeff,
> i haven't played with interbase yet, but my understanding is they have
> two types of server -- the "classic" (process per connection?) and a
> "superserver" (multithreaded). i'm guessing the multithreaded is faster
> (why bother with the added complexity if it isn't?) so which version
> did you run this test against?
Classic. Superserver didn't work with the ODBC driver. Richard Brosnahan,
the lead engineer on the project at Xperts, could connect, but could not
successfully build tables and load them due to SQL errors. Feel free to
contact him directly (he's cc'ed here).
> the other question i have is if it was possible that the disks were a
> bottleneck in the test process. it seems strange that three databases
> would perform nearly identically for so long if there wasn't a
> bottleneck somewhere. were the drives striped? did you consider
> performing the test with faster raid arrays?
The disks were not striped. We may look at RAID in the future, but again,
this was only a simple low-end test. It seems reasonable to assume that the
disks were a bottleneck, but they would have been a bottleneck for all of
the databases.
> on a related note, i was
> looking through a couple of back issues of db2 magazine, and it struck
> me how much optimization and other performance hints there were
> available there & how little there was for postgres. is great bridge
> planning on creating a knowledge base of these optimizations for the
> public? or are you planning optimization as one of the commercial
> services you provide? or some of both?
Yes, yes, and yes. We'll have more to say about our commercial services in
the near future, but there will always be a substantial free, publicly
available knowledgebase as part of our commitment to the open source
community.
Regards,
Ned
