Re: Tables on multiple disk drives - Mailing list pgsql-performance

From Christopher Browne
Subject Re: Tables on multiple disk drives
Date
Msg-id m34qtpuymo.fsf@wolfe.cbbrowne.com
Whole thread Raw
In response to Tables on multiple disk drives  (Konstantin Tokar <lists2@tokar.ru>)
List pgsql-performance
lists2@tokar.ru (Konstantin Tokar) wrote:
> Hi!
> Does PostgreSQL allow to create tables and indices of a single
> database on multiple disk drives with a purpose of increase
> performance as Oracle database does? If a symbolic reference is the
> only method then the next question is: how can it be determined what
> file is referred to what table and index?

It is possible to do this, albeit not trivially easily, by shutting
down the database, moving the index to another filesystem, and using a
symbolic link to connect it back in.  The system table pg_class
contains the relevant linkages.

But it seems likely to me that using a smart RAID controller (e.g. -
LSILogic MegaRAID) to link a whole lot of disks together to generate
one enormous striped filesystem would be a more effective strategy, in
the long run.

Doing that, with a substantial array of disk drives, allows your disk
subsystem to provide an analagous sort of performance increase without
there being any need for a DBA to fiddle around with anything.

If you have the DBA do the work, this means consuming some
not-insubstantial amount of time for analysis as well as down-time for
maintenance.  And it will be necessary to have a somewhat-fragile
"registry" of configuration information indicating what customizations
were done.

In contrast, throwing a smarter RAID controller at the problem costs
only a few hundred dollars, and requires little or no analysis effort.
And the RAID controller will affect _all_ cases where there could be
I/O benefits from striping tables across multiple drives.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://cbbrowne.com/info/x.html
The way to a man's heart is through the left ventricle.

pgsql-performance by date:

Previous
From: PC Drew
Date:
Subject: Re: long running query running too long
Next
From: Tom Lane
Date:
Subject: Re: long running query running too long