 | This is a multi-part message in MIME format.
------=_NextPart_000_001D_01C5022D.4B8098F0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Hello everyone,
First time poster to the mailing list here.=20
We have been running pgsql for about a year now at a pretty basic level =
(I guess) as a backend for custom web (intranet) application software. =
Our database so far is a "huge" (note sarcasm) 10 Mb containing of about =
6 or so principle tables.=20
Our 'test' screen we've been using loads a 600kb HTML document which is =
basically a summary of our client's orders. It took originally 11.5 =
seconds to load in internet explorer (all 10.99 seconds were pretty much =
taken up by postgres processes on a freebsd server).=20
I then re-wrote the page to use a single select query to call all the =
information needed by PHP to draw the screen. That managed to shave it =
down to 3.5 seconds... but this so far is as fast as I can get the page =
to load. Have tried vacuuming and creating indexes but to no avail. =
(increasing shared mem buffers yet to be done)
Now heres the funny bit ...=20
Every time I tested an idea to speed it up, I got exactly the same =
loading time on a Athlon 1800+, 256Mb RAM, 20Gb PATA computer as =
compared to a Dual Opteron 246, 1Gb RAM, 70Gb WD Raptor SATA server. =
Now, why a dual opteron machine can't perform any faster than a lowly =
1800+ athlon in numerous tests is completely beyond me ... increased =
memory and RAID 0 disc configurations so far have not resulted in any =
significant performance gain in the opteron server.
Do these facts sound right? If postgres is meant to be a 200Gb =
industrial strength database, should it really be taking this long =
pulling 600kb worth of info from a 10Mb database? And why no performance =
difference between two vastly different hardware spec'd computers??? Am =
I missing some vital postgres.conf setting??
Any advice welcome.
Thanks,
Dave
space_ball_one@hotmail.com
------=_NextPart_000_001D_01C5022D.4B8098F0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
charset=3Diso-8859-1">
Hello everyone,
First time =
poster to the=20
mailing list here.
We have been running pgsql for about a =
year now at=20
a pretty basic level (I guess) as a backend for custom=20
web (intranet) application software. Our database so far =
is a=20
"huge" (note sarcasm) 10 Mb containing of about 6 or so principle=20
tables.
Our 'test' screen we've been using =
loads a 600kb=20
HTML document which is basically a summary of our client's orders. =
It took=20
originally 11.5 seconds to load in internet explorer (all 10.99 seconds =
were=20
pretty much taken up by postgres processes on a freebsd server). =
I then re-wrote the page to use a =
single select=20
query to call all the information needed by PHP to draw the screen. =
That=20
managed to shave it down to 3.5 seconds... but this so far is as fast as =
I can=20
get the page to load. Have tried vacuuming and creating indexes but to =
no avail.=20
(increasing shared mem buffers yet to be done)
Now heres the funny bit ... =
Every time I=20
tested an idea to speed it up, I got exactly the same loading time on a =
Athlon=20
1800+, 256Mb RAM, 20Gb PATA computer as compared to a Dual Opteron 246, =
1Gb RAM,=20
70Gb WD Raptor SATA server. Now, why a dual opteron machine can't =
perform=20
any faster than a lowly 1800+ athlon in numerous tests is completely =
beyond me=20
... increased memory and RAID 0 disc configurations so far have not =
resulted in=20
any significant performance gain in the opteron server.
Do these facts sound right? If postgres =
is meant to=20
be a 200Gb industrial strength database, should it really be taking this =
long=20
pulling 600kb worth of info from a 10Mb database? And why no performance =
difference between two vastly different hardware spec'd computers??? Am =
I=20
missing some vital postgres.conf setting??
Any advice=20
welcome.
Thanks,
Dave
href=3D"mailto:space_ball_one@hotmail.com">space_ball_one@hotmail.com=
------=_NextPart_000_001D_01C5022D.4B8098F0--
|
