[Fwd: Re: CPU types and queries...] - Mailing list pgsql-novice

From Ron Johnson
Subject [Fwd: Re: CPU types and queries...]
Date
Msg-id 1022714995.17105.14.camel@rebel
Whole thread Raw
List pgsql-novice
And, of course, you VACUUM ANALYZE each database nightly...

-----Forwarded Message-----

> From: Ron Johnson <ron.l.johnson@cox.net>
> To: James Kelty <jamesk@ashlandagency.com>
> Subject: Re: [NOVICE] CPU types and queries...
> Date: 29 May 2002 18:27:04 -0500
>
> On Wed, 2002-05-29 at 16:00, James Kelty wrote:
> >
> >
> > Hello,
> >
> > A question was recently brought up at my place of business about CPU
> > types, and Postgres.
> >
> > We have Two systems, both running Red Hat 7.2, both with 4Gig's of PC133
> > memory.
> >
> > The first system has TWO 933Mhz Intel PIII (Coppermine) procs, and a
> > certain query returns VERY fast, around 2 seconds.
> >
> > The second system has TWO 700Mhx Intel PIII Xeon (Cascades) procs, but
> > the same query from the same code from the same web server takes approx.
> > 10-12 seconds.
> >
> > Is there REALLY that much difference between the two proc types? Will
> > 233Mhz actually make THAT much of a difference?
> >
> > What about the big Xeon cache? 1Mb vs. the Coppermine 256k cache?
>
> This is presuming that the databases are the same size, and reside
> on exactly the same kind of disks, controllers, shared_buffers size,
> indexes, number of rows, etc, right?

--
+---------------------------------------------------------+
| Ron Johnson, Jr.        Home: ron.l.johnson@cox.net     |
| Jefferson, LA  USA      http://ronandheather.dhs.org:81 |
|                                                         |
| "I have created a government of whirled peas..."        |
|   Maharishi Mahesh Yogi, 12-May-2002,                   |
!   CNN, Larry King Live                                  |
+---------------------------------------------------------+


pgsql-novice by date:

Previous
From: Josh Berkus
Date:
Subject: Re: Database Ownership
Next
From: danix@cloud9.net (danix)
Date:
Subject: ideal filesystem layout