On 2/27/07, Shane Ambler [EMAIL PROTECTED] wrote:
Jeff Davis wrote:
Sorry for for not being familar with storage techonologies... Does
battery here mean battery in the common sense of the word - some
kind of independent power supply? Shouldn't the disk itself be backed
by a battery? As
On Mon, Feb 26, 2007 at 04:24:12PM -0500, Charles Sprickman wrote:
On Mon, 26 Feb 2007, Madison Kelly wrote:
Hi all,
I'd really like to come up with a more intelligent search engine that
doesn't take two minutes to return results. :) I know, in the end good
indexes and underlying
We have been running Postgres on a 2U server with 2 disks configured in
raid 1 for the os and logs and 4 disks configured in raid 10 for the
data. I have since been told raid 5 would have been a better option
given our usage of Dell equipment and the way they handle raid 10. I
have just a few
Magnus Hagander wrote:
Just as a datapoint, we did try to use mnogosearch for the
postgresql.org website+archives search, and it fell over completely.
Indexing took way too long, and we had search times several thousand
times longer than with tsearch2.
That said, I'm sure there are cases
Joe Uhl wrote:
We have been running Postgres on a 2U server with 2 disks configured in
raid 1 for the os and logs and 4 disks configured in raid 10 for the
data. I have since been told raid 5 would have been a better option
given our usage of Dell equipment and the way they handle raid 10. I
Just remember that batteries (in both RAID cards and UPSes) wear out
and will eventually have to be replaced. It depends how critical your
data is, but if you only have a UPS, you risk badness in the off
chance that your power fails and you haven't replaced your UPS battery.
On Feb 27,
At 08:12 AM 2/27/2007, Joe Uhl wrote:
We have been running Postgres on a 2U server with 2 disks configured in
raid 1 for the os and logs and 4 disks configured in raid 10 for the
data. I have since been told raid 5 would have been a better option
given our usage of Dell equipment and the way
Hope you don't mind, Ron. This might be splitting hairs.
On Tue, Feb 27, 2007 at 11:05:39AM -0500, Ron wrote:
The real CPU overhead when using SW RAID is when using any form of SW
RAID that does XOR operations as part of writes (RAID 5, 6, 50, ...,
etc). At that point, you are essentially
Ok, looks like the FreeBSD community is interested in PostgreSQL
performance, or at least enough to investigate it.
Anyone here have experience hacking on FreeBSD?
- Forwarded message from Kris Kennaway [EMAIL PROTECTED] -
X-Spam-Checker-Version: SpamAssassin 3.1.6 (2006-10-03) on
Peter Kovacs wrote:
The reason this becomes an issue is that many consumer-grade disks have
write cache enabled by default and no way to make sure the cached data
actually gets written. So, essentially, these disks lie and say they
wrote the data, when in reality, it's in volatile memory.
Jim C. Nasby [EMAIL PROTECTED] writes:
Ok, looks like the FreeBSD community is interested in PostgreSQL
performance, or at least enough to investigate it.
I think this guy is barking up the wrong tree though, because we don't
ever have multiple processes sleeping on the same sema. Not that
On Tue, 2007-02-27 at 12:28, Joe Uhl wrote:
Really appreciate all of the valuable input. The current server has the
Perc4ei controller.
The impression I am taking from the responses is that we may be okay with
software raid, especially if raid 1 and 10 are what we intend to use.
I think
On Tue, 2007-02-27 at 13:23, Jeff Davis wrote:
Also, put things in context. The chances of failure due to these kinds
of things are fairly low. If it's more likely that someone spills coffee
on your server than the UPS fails, it doesn't make sense to spend huge
amounts of money on NVRAM (or
Madison Kelly wrote:
Hi all,
I am asking in this list because, at the end of the day, this is a
performance question.
I am looking at writing a search engine of sorts for my database. I
have only ever written very simple search engines before which amounted
to not much more that the
On Tue, 27 Feb 2007, Dave Page wrote:
Magnus Hagander wrote:
Just as a datapoint, we did try to use mnogosearch for the
postgresql.org website+archives search, and it fell over completely.
Indexing took way too long, and we had search times several thousand
times longer than with tsearch2.
Joe Uhl wrote:
[1] What is the performance penalty of software raid over hardware raid?
Is it truly significant? We will be working with 100s of GB to 1-2 TB
of data eventually.
One thing you should appreciate about hw vs sw raid is that with the former
you can battery-back it and enable
16 matches
Mail list logo
