Skip site navigation (1) Skip section navigation (2)

Re: Anyone using a SAN?

From: Tobias Brox <tobias(at)nordicbet(dot)com>
To: Peter Koczan <pjkoczan(at)gmail(dot)com>
Cc: pgsql-performance <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Anyone using a SAN?
Date: 2008-02-13 21:06:55
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
[Peter Koczan - Wed at 10:56:54AM -0600]
> We're considering setting up a SAN where I work. Is there anyone using
> a SAN, for postgres or other purposes? If so I have a few questions
> for you.

Some time ago, my boss was planning to order more hardware - including a
SAN - and coincidentally, SANs were discussed at this list as well.
The consensus on this list seemed to be that running postgres on SAN is
not cost efficiently - one would get better performance for a lower cost
if the database host is connected directly to the disks - and also,
buying the wrong SAN can cause quite some problems.

My boss (with good help of the local SAN-pusher) considered that the
arguments against the SAN solution on this list was not really valid for
an "enterprise" user.  The SAN-pusher really insisted that through a
state-of-the-art SAN theoretically it should be possible to achieve far
better bandwidth as well as lower latency to the disks.  Personally, I
don't have the clue, but all my colleagues believes him, so I guess he
is right ;-)  What I'm told is that the state-of-the-art SAN allows for
an "insane amount" of hard disks to be installed, much more than what
would fit into any decent database server.  We've ended up buying a SAN,
the physical installation was done last week, and I will be able to tell
in some months if it was a good idea after all, or not.

In response to


pgsql-performance by date

Next:From: Scott MarloweDate: 2008-02-13 21:36:07
Subject: Re: Join Query Perfomance Issue
Previous:From: Gregory StarkDate: 2008-02-13 20:51:34
Subject: Re: Optimizing No matching record Queries

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group