On 11/30/07, Wolfgang Keller <wolfgang.keller.privat@xxxxxx> wrote:
> > For example, if you have an application that needs high
> > database write throughput, to make that work well with PostgreSQL you
> > must have a controller with a battery backed cache.
> Hmm, what would be the difference compared to plenty of RAM and a UPS
> (plus stand-by backup server)? Looks just like moving the "single point
> of failure" to adifferent hardware item, no...?
Well, you want a backup server anyway, for completely different
reasons. It's not relevant to write throughput.
The difference between using a disk controller with a BBC compared to
just turning fsync off and using RAM is that you've introduced an
additional point of failure: the OS itself. You have to trust that the
OS is always going to be able to write the cached data to disk. That
tends to be riskier than relying on a piece of hardware dedicated to
the job, simply because an OS does more, and therefore has more to go
wrong (kernel panic / grey screen / BSOD).
You could make similar arguments about the additional hardware
components in the chain, like the internal power supply. The point is
that the database expects that when it asked for data to hit disk, it
actually got there. A BBC allows a disk controller to lie (reliably),
but turning fsync off allows pretty much everything from the OS down
to lie (somewhat less reliably).
The controller always exists, so it's not moving a point of failure;
if a controller goes you've lost the disk anyway.
The tradeoff is how much trust you're willing to put into various
parts of the system being uninterrupted.
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
