Nemanja Corlija <[EMAIL PROTECTED]> wrote: > I've posted some benchmarks between SQLite, PostgreSQL, MySQL and FirebirdS= > QL. > > Details at http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison >
Thanks for your hard work, Nemanja! This is useful information. Looks like I need to work on Test 6 some, huh? Your suggestion that the servers are creating a temporary index to do the join was my first throught too. I wonder if I should look into teaching that trick to SQLite. Do you think you might add another test (6b?) that repeated the same join after indexing one of the join columns? You do this at Test 13, but at that point the tables contain different data, I think. Other people have posted that the PostgreSQL tests are meaningless because the database is not tuned. I am someone sympathetic to their complaints. If you have time, I think it would be useful to show both a tuned and and untuned version for PostgreSQL. It is also useful to know that PostgreSQL needs tuning in order to run well. It is also interesting to note that PostgreSQL get significantly slower in Test 13 (join with an index) versus Test 6 (the same join without an index). What is that about? Firebird shows the same effect, but less dramatically. Could it be a difference in the data that the tables hold at that point. Test 6B proposed above really would be instructive here, I think. I also wonder if MySQL and Firebird would benefit from tuning. The MySQL people are rather laid back and probably will say something like "whatever" if asked. The Firebird crowd, on the other hand, tend to be edgy and I suspect we will be hearing some pointed commentary from them in the near future. Is there any chance of seeing additional information such as the amount of disk space used by the various databases or the amount of RAM consumed? These values would be more difficult to arrive at, but will be helpful to many people, I think, if available. Thanks again for your hard work in preparing these benchmarks! Even if you do nothing else with them, your work so far has been a big help. -- D. Richard Hipp <[EMAIL PROTECTED]>
