* Chris Browne:
A dedicated RAID controller with battery-backed cache of ssuficient
size and two mirrored disks should not perform that bad, and has the
advantage of easy availability.
That won't provide as souped up performance as WAL on SSD, and
it's from technical people wishing for
On Wed, Jan 23, 2008 at 07:54:24PM -0500, Greg Smith wrote:
(a standard mechanical drive under heavy write load also wears out faster
than one doing less work).
Wasn't this one of the myths that was dispelled in the Google disk paper a
while ago?
/* Steinar */
--
Homepage:
On Jan 23, 2008 2:57 PM, Guy Rouillier [EMAIL PROTECTED] wrote:
Unless somebody has changes some physics recently, I'm not understanding
the recent discussions of SSD in the general press. Flash has a limited
number of writes before it becomes unreliable. On good quality consumer
grade,
On Wed, 23 Jan 2008, Brian Hurt wrote:
I think the original poster was talking about drives like these:
http://www.texmemsys.com/
Basically, they're not using Flash, they're just big ol' hunks of
battery-backed RAM. Not unlike a 10GB battery backed buffer for your raid,
except there is no
So, that web site seems to list products starting at about 32GB in a
separate rack-mounted box with redundant everything. I'd be more
interested in just putting the WAL on an SSD device, so 500MB or 1GB
would be quite sufficient. Can anyone point me towards such a device?
A dedicated RAID
[EMAIL PROTECTED] (Scott Marlowe) writes:
On Jan 23, 2008 1:57 PM, Guy Rouillier [EMAIL PROTECTED] wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server will
be a better way to spend
[EMAIL PROTECTED] (Florian Weimer) writes:
So, that web site seems to list products starting at about 32GB in a
separate rack-mounted box with redundant everything. I'd be more
interested in just putting the WAL on an SSD device, so 500MB or 1GB
would be quite sufficient. Can anyone point me
On Jan 22, 2008 11:11 PM, Joshua Fielek [EMAIL PROTECTED] wrote:
The database itself is not that large -- a db_dump of the sql file as
text is only about 110MB. I haven't checked the exact size of the actual
data base, but the entire data directory is smaller than the available
memory at about
On Jan 24, 2008 1:01 PM, Merlin Moncure [EMAIL PROTECTED] I'll
give you a little hint about postgresql.conf...tuning shared
buffers rarely has a huge impact on performance...the o/s will
oops. i meant to say the o/s will cache the files just fine...the
setting that _does_ affect query
In response to Joshua Fielek [EMAIL PROTECTED]:
Hey folks --
For starters, I am fairly new to database tuning and I'm still learning
the ropes. I understand the concepts but I'm still learning the real
world impact of some of the configuration options for postgres.
We have an
On Jan 23, 2008 8:01 AM, mike long [EMAIL PROTECTED] wrote:
Scott,
What are your thoughts on using one of those big RAM appliances for
storing a Postgres database?
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your
Josh what about the rest of your system? What operating system? Your
hardware setup. Drives? Raids? What indices do you have setup for
these queries? There are other reasons that could cause bad queries
performance.
On Jan 22, 2008 11:11 PM, Joshua Fielek [EMAIL PROTECTED] wrote:
Hey folks
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server will
be a better way to spend your money. For certain high throughput,
relatively small databases (i.e. transactional work) the SSD can be
Guy Rouillier wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server will
be a better way to spend your money. For certain high throughput,
relatively small databases (i.e. transactional
On Jan 23, 2008, at 2:57 PM, Guy Rouillier wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server
will
be a better way to spend your money. For certain high throughput,
relatively
Guy Rouillier wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server will
be a better way to spend your money. For certain high throughput,
relatively small databases (i.e. transactional
On Wed, 23 Jan 2008, Guy Rouillier wrote:
Flash has a limited number of writes before it becomes unreliable. On
good quality consumer grade, that's about 300,000 writes, while on
industrial grade it's about 10 times that.
The main advance that's made SSD practical given the write cycle
On Jan 23, 2008 1:57 PM, Guy Rouillier [EMAIL PROTECTED] wrote:
Scott Marlowe wrote:
I assume you're talking about solid state drives? They have their
uses, but for most use cases, having plenty of RAM in your server will
be a better way to spend your money. For certain high throughput,
Hey folks --
For starters, I am fairly new to database tuning and I'm still learning
the ropes. I understand the concepts but I'm still learning the real
world impact of some of the configuration options for postgres.
We have an application that has been having some issues with performance
On Jan 22, 2008 10:11 PM, Joshua Fielek [EMAIL PROTECTED] wrote:
Hey folks --
For starters, I am fairly new to database tuning and I'm still learning
the ropes. I understand the concepts but I'm still learning the real
world impact of some of the configuration options for postgres.
We have
20 matches
Mail list logo
