Michael Adler wrote:
On Thu, Oct 07, 2004 at 11:48:41AM -0400, Bill Montgomery wrote:
Alan Stange wrote:
The same test on a Dell PowerEdge 1750, Dual Xeon 3.2 GHz, 512k cache,
HT on, Linux 2.4.21-20.ELsmp (RHEL 3), 4GB memory, pg 7.4.5:
Far less performance that the Dual Opterons with a low
Alan Stange wrote:
Here's a few numbers from the Opteron 250. If I get some time I'll
post a more comprehensive comparison including some other systems.
The system is a Sun v20z. Dual Opteron 250, 2.4Ghz, Linux 2.6, 8 GB
memory. I did a compile and install of pg 8.0 beta 3. I created a
dat
not relevant to this post).
Anything blatantly stupid in there for my setup?
Thanks,
Bill Montgomery
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
st database servers, am I really truly CPU
bound now, and not just suffering from poorly handled spinlocks on my
Xeon/ServerWorks platform? If so, is the expense of a 64-bit system
worth it, or is the price/performance for PostgreSQL still better on an
alternative 32-bit platform, like AthlonM
urgent need to scale upward. Thoughts? General wisdom?
Best Regards,
Bill Montgomery
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Josh Berkus wrote:
Does the order of columns of varying size have any effect on
SELECT/INSERT/UPDATE/and/or/DELETE performance? Take the example where
an integer primary key is listed first in the table and alternatively
listed after some large varchar or text columns?
No, the "order" of the c
.
Good Luck,
Bill Montgomery
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs/FAQ.html
st Regards,
Bill Montgomery
---(end of broadcast)---
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
your memory filled with
useless data. Better to let the smarter filesystem cache handle the bulk
of your caching needs.
Comments and advice gratefully received.
Rory
Best Luck,
Bill Montgomery
---(end of broadcast)---
TIP 9: the planner will ignor
est you can do
performance-wise; if your budget for disks is limited, RAID 5 is the
next best thing. Also, you will get more bang for your buck with a
larger number of 10k disks than a smaller number of 15k disks.
Good luck,
Bill Montgomery
---(end of broadcast)-
frequent write operations require more frequent vacuuming.
Good luck.
Best Regards,
Bill Montgomery
The postresql.conf say:
#---
# RESOURCE USAGE (
n
dismal. It didn't help :-(
Best Regards,
Bill Montgomery
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
7.92 sec.
INFO: Removed 77066 tuples in 3474 pages.
CPU 0.38s/0.32u sec elapsed 1.33 sec.
INFO: Pages 13295: Changed 276, Empty 0; Tup 34540: Vac 77066, Keep 0,
UnUsed 474020.
Total CPU 3.34s/1.29u sec elapsed 125.00 sec.
INFO: Analyzing public.xxx
Best Regards,
Bill Montgomery
13 matches
Mail list logo
