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

Re: tablespaces and DB administration

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: James Robinson <jlrobins(at)socialserve(dot)com>
Cc: pgsql(at)mohawksoft(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: tablespaces and DB administration
Date: 2004-05-27 09:29:54
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
James Robinson wrote:

>> Users are primarily, if not stupid, ignorant. They will read the 
>> absolute
>> minimum needed to achieve a goal and little else. I say this with the
>> utmost respect, because I and probably everyone else on this group is
>> guilty of the same thing. So, the "preferred" installation procedure, 
>> i.e.
>> the one with the easy to follow directions, should showcase features the
>> user should know, and leave the user in a good place. IMHO, the user's
>> database on one volume and pg_xlog on another is a better starting 
>> place.
> Yes, that is generally the case (prefer pg_xlog on separate spindle), 
> but no
> need to *forcibly* overcomplicate things if the box has only one spindle,
> or if they have only one single RAID'd partition configured. We should
> continue to err on the side of keeping the path to a functional system
> nice and simple, yet still offering superb functionality. Oracle gets 
> this
> wrong. pg_autovacuum is another good step in this direction.

In the age of inexpensive RAID, tablespaces have more or less lost their 
relevance regarding performance. pgsql's philosophy respects this by 
leaving the storage work up to the OS and disk subsystem. Even having 
the xlog on a different spindle won't help too much; you'll probably be 
better off if you stuff all your spindles in one raid on most systems. 
For worse, splitting two disks into separate storage areas to have xlog 
separated would degrade safety for very little performance gain. So the 
advise is: one disk, no alternative. 2 to 20 disks: use a single raid. 
more disks: examine your access patterns carefully before you believe 
you can do the job better than your raid controller.

This leaves table spaces as a mere administrative feature, many (most) 
installations will happily live without that.


In response to


pgsql-hackers by date

Next:From: pgsqlDate: 2004-05-27 12:41:55
Subject: Re: tablespaces and DB administration
Previous:From: Zeugswetter Andreas SB SDDate: 2004-05-27 08:36:25
Subject: Re: SELECT * FROM <table> LIMIT 1; is really slow

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