On Sat, Feb 11, 2006 at 08:06:56PM -0500, Tom Lane wrote: > Jochem van Dieten <[EMAIL PROTECTED]> writes: > > On 2/11/06, Andrej Ricnik-Bay wrote: > >> http://www.sqlite.org/cvstrac/wiki?p=SpeedComparison > > > The values appear to originate from an intrsinsically flawed test setup. > > > Just take the first test. The database has to do 1000 commits. That > > means 1000 I/O operations. There is no way that a 7200 RPM disk can do > > that in the time that that test says it took. It is reasonable to say > > that a disk can do 1 I/O operation per rotation, which means that any > > test result below 9 seconds is untrustworthy. > > Disk lying about write-complete, no doubt. Of course that probably > affects all the databases about the same. > > The fact that it's on Windows is probably handicapping us noticeably, > considering that that port still isn't well optimized. > > Test 8's problem is most likely lack of an ANALYZE --- although when > I tried to duplicate it, I got a bitmap index scan, which shouldn't be > horrendously slow. There's something fishy about that one.
FWIW, here's a thread about this test: http://www.mail-archive.com/sqlite-users%40sqlite.org/msg12945.html Part of the problem seems to be related to psql; he was able to run test 8 in about 5 seconds using pgAdmin: http://www.mail-archive.com/sqlite-users%40sqlite.org/msg12955.html -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
