On 2/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > 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. I guess I'll just copy test 13 to where test 8 is right now. Though those test numbers will likely create a lot of confusion that way.
> 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. At first, I wanted to get by cheaply by not tuning anything. But yeah, tuning each database would be a sensible thing to do after all. > 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 suspect that postgres and firebird just lost track of what's in the database at that point and they could really use some ANALYZE at that point. Just an assumption though. > 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. I'd like to gather some input on this and then rerun test after that. So if you have some tips for optimizing any database involved, please speak up. > 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. I don't have much of those information ATM, but I will tell you that SQLite3 used 3MB, while SQLite2 used 3.8MB for the duration of test 6 and they both used up all CPU. Will try to gather information about database sizes next time. But I don't know how can I reliably measure memory usage on windows. -- Nemanja Corlija <[EMAIL PROTECTED]>
