Ok, the production server is a Celeron 433, 512 MEgs of PC100 ECC RAM, 2 18
Gig Ultra 160 SCSI drives (only running at 80 megs since we dono't have a
64-bit PCI slot).
There is a big upgrade planned for this box when the motherboard we're
waiting for comes out..
The development server is a PII450, 128 Megs of RAM and Ultra 2 SCSI
drives.. However it's running several other things other than the database
and webserver so it has a small load.
Sorry for not replying sooner, had a small crisis yesterday evening :-)
- Mitch
----- Original Message -----
From: The Hermit Hacker <scrappy@hub.org>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Mitch Vincent <mitch@huntsvilleal.com>; <pgsql-hackers@postgresql.org>
Sent: Thursday, May 04, 2000 1:51 AM
Subject: Re: system usage stats (Was: Re: [HACKERS] Why Not MySQL? )
> On Thu, 4 May 2000, Tom Lane wrote:
>
> > The Hermit Hacker <scrappy@hub.org> writes:
> > > Now, Mitch's results for v7.0 showed something like:
> > > 0/12 filesystem blocks in/out
> > > You intepreted that as 12 reads from the file system ... 'out' I would
> > > have interpreted as writes to the file system, which made zero sense
> > > ... do we have our 'in/out's backwards here?
> >
> > Good point. Writes from a SELECT are certainly possible --- the SELECT
> > could be writing tuple status-flag updates, if it was the first
> > transaction to verify commit status of tuples created by a prior
> > transaction. But that again raises the issue of whether we've got
> > a fair comparison. The 6.5 test apparently only saw already-marked-
> > committed tuples ...
>
> I was hoping that Mitch would have spoken up by now about it, but an email
> I saw from him stated that the v7.0 machine (development) wasn't as
> powerful as the v6.5.3 machine (production) ... that might account for it,
> I just don't know how much different the two machines are ...
>
> Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
> Systems Administrator @ hub.org
> primary: scrappy@hub.org secondary:
scrappy@{freebsd|postgresql}.org
>
