Re: SpeedComparison

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jochem van Dieten <jochemd(at)gmail(dot)com>
Cc: Andrej Ricnik-Bay <andrej(dot)groups(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: SpeedComparison
Date: 2006-02-12 01:06:56
Message-ID: 954.1139706416@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jochem van Dieten <jochemd(at)gmail(dot)com> 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.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Chris Browne 2006-02-12 01:57:47 Re: How to VACUUM this table? "998994633 estimated total rows"
Previous Message Tom Lane 2006-02-12 00:50:22 Re: Scrollable cursors and Sort performance