On May 21, 2008, at 12:33 AM, Shane Ambler wrote:
Size can affect performance as much as anything else.
For a brief moment, I thought the mailing list had been spammed. ;-)
J. Andrew Rogers
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes
suggest that XFS is a fine
and safe choice for your application.
J. Andrew Rogers
---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings
with 64-bit Linux on
Opterons because the AMD64 systems tend to be both faster and
cheaper. Architectures like Sparc have never given us problems, but
they have not exactly thrilled us with their performance either.
Cheers,
J. Andrew Rogers
---(end of broadcast
significantly from the P4 in
capability.
J. Andrew Rogers
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
and the upgrade cost is below the noise floor for
most database servers.
J. Andrew Rogers
---(end of broadcast)---
TIP 6: explain analyze is your friend
On Dec 12, 2005, at 2:19 PM, Vivek Khera wrote:
On Dec 12, 2005, at 5:16 PM, J. Andrew Rogers wrote:
We've swapped out the DIMMs on MegaRAID controllers. Given the
cost of a standard low-end DIMM these days (which is what the LSI
controllers use last I checked), it is a very cheap upgrade
you are doing a lot of math on
the results.
YMMV, as always. Recommendations more specific than Opterons rule, Xeons
suck depend greatly on what you plan on doing with the database.
Cheers,
J. Andrew Rogers
---(end of broadcast)---
TIP 9
v2.6.12 kernel that I know of is FC4, which
is not really supported in the enterprise sense of course.
J. Andrew Rogers
---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster
. Using the patched kernel, one gets the
performance most people were expecting.
The v2.6.12+ kernels are a bit new, but they contain a very important
performance patch for systems like the one above. It would definitely be
worth testing if possible.
J. Andrew Rogers
it
is at least as fast as XFS for Postgres.
Since XFS is more mature than JFS on Linux, I go with XFS
by default. If some tragically bad problems develop with
XFS I may reconsider that position, but we've been very
happy with it so far. YMMV.
cheers,
J. Andrew Rogers
of
date anyway).
J. Andrew Rogers
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
needs.
Cheers,
J. Andrew Rogers
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
replacement.
My random thought of the day,
j. andrew rogers
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
solution.
cheers,
j. andrew rogers
---(end of broadcast)---
TIP 7: don't forget to increase your free space map settings
and association is the ugly part when rolling your own.
Intercepting DML when necessary and making it behave correctly is
already pretty easy, but could probably be streamlined.
j. andrew rogers
---(end of broadcast)---
TIP 9: the planner will ignore
on heavily used tables
with tens of millions of rows, we frequently got a 10x or better
performance improvement on queries against those tables. It is only
really useful for tables with vast quantities of relatively small rows,
but it can be a lifesaver in those cases.
J. Andrew Rogers
of those
options that needs to be used knowledgeably; it is not a general
architectural improvement that you would want to apply to every table
all the time.
J. Andrew Rogers
---(end of broadcast)---
TIP 3: if posting/reading through Usenet
and the Tyan quad motherboard, and the sum comes out to a
very reasonable number for what you are getting.
j. andrew rogers
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faqs
-through, and IIRC, three
different algorithms for reading (none, read-ahead, adaptive). Plenty
of configuration options.
It is a pretty mature and feature complete hardware RAID implementation.
j. andrew rogers
---(end of broadcast)---
TIP 6
of workloads that it doesn't do so
well on, but for many normal DBMS loads it scales quite well.
j. andrew rogers
---(end of broadcast)---
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do
I verified problem on a Dual Opteron server. I temporarily killed the
normal load, so the server was largely idle when the test was run.
Hardware:
2x Opteron 242
Rioworks HDAMA server board
4Gb RAM
OS Kernel:
RedHat9 + XFS
1 proc: 10-15 cs/sec
2 proc: 400,000-420,000 cs/sec
j. andrew
database hardware in general
for us.
j. andrew rogers
---(end of broadcast)---
TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
your
disk system hard (like we do). For databases with low disk I/O
intensity, stay with IDE/SATA and save a little money. For databases
that have high disk I/O intensity, use SCSI. The price premium for SCSI
is about 50%, but the performance difference is an integer factor under
load.
j. andrew
23 matches
Mail list logo
