Index: doc/src/sgml/diskusage.sgml =================================================================== RCS file: /usr/local/cvsroot/pgsql-server/doc/src/sgml/diskusage.sgml,v retrieving revision 1.10 diff -2 -c -r1.10 diskusage.sgml *** doc/src/sgml/diskusage.sgml 29 Nov 2003 19:51:36 -0000 1.10 --- doc/src/sgml/diskusage.sgml 19 Jun 2004 11:13:02 -0000 *************** *** 125,136 **** If you cannot free up additional space on the disk by deleting ! other things you can move some of the database files to other file ! systems and create a symlink from the original location. But ! note that pg_dump cannot save the location layout ! information of such a setup; a restore would put everything back in ! one place. To avoid running out of disk space, you can place the ! WAL files or individual databases in other locations while creating ! them. See the initdb documentation and for more information about that. --- 125,130 ---- If you cannot free up additional space on the disk by deleting ! other things you can make use of tablespaces. See for more information about that. Index: doc/src/sgml/manage-ag.sgml =================================================================== RCS file: /usr/local/cvsroot/pgsql-server/doc/src/sgml/manage-ag.sgml,v retrieving revision 2.30 diff -2 -c -r2.30 manage-ag.sgml *** doc/src/sgml/manage-ag.sgml 18 Jun 2004 06:13:02 -0000 2.30 --- doc/src/sgml/manage-ag.sgml 19 Jun 2004 12:35:10 -0000 *************** *** 296,379 **** - - Alternative Locations - - - XXX this is entirely dead now, and needs to be replaced by a DBA-level - description of tablespaces. - - - - It is possible to create a database in a location other than the - default location for the installation. But remember that all database access - occurs through the - database server, so any location specified must be - accessible by the server. - - - - Alternative database locations are referenced by an environment - variable which gives the absolute path to the intended storage - location. This environment variable must be present in the server's - environment, so it must have been defined before the server - was started. (Thus, the set of available alternative locations is - under the site administrator's control; ordinary users can't - change it.) Any valid environment variable name may - be used to reference an alternative location, although using - variable names with a prefix of PGDATA is recommended - to avoid confusion and conflict with other variables. - - - - To create the variable in the environment of the server process - you must first shut down the server, define the variable, - initialize the data area, and finally restart the server. (See also - and .) To set an environment variable, type - - PGDATA2=/home/postgres/data - export PGDATA2 - - in Bourne shells, or - - setenv PGDATA2 /home/postgres/data - - in csh or tcsh. You have to make sure that this environment - variable is always defined in the server environment, otherwise - you won't be able to access that database. Therefore you probably - want to set it in some sort of shell start-up file or server - start-up script. - - - - initlocation - To create a data storage area in PGDATA2, ensure that - the containing directory (here, /home/postgres) - already exists and is writable - by the user account that runs the server (see ). Then from the command line, type - - initlocation PGDATA2 - - (not initlocation - $PGDATA2). Then you can restart the server. - - - - To create a database within the new location, use the command - - CREATE DATABASE name WITH LOCATION 'location'; - - where location is the environment variable you - used, PGDATA2 in this example. The createdb - command has the option - - - Databases created in alternative locations can be - accessed and dropped like any other database. - - - Destroying a Database --- 296,299 ---- *************** *** 410,413 **** --- 330,421 ---- the database with the current user name.) + + + + Tablespaces + + + + + + Tablespaces in + PostgreSQL allow database superusers to define + locations on the file system where the binary files associated with + database objects can be stored. Once + created, a tablespace can be referred to by name when creating database + objects. + + + + This means that, using tablespaces, a database administrator can control + disk usage by PostgreSQL. This is useful in at least + two ways. Firstly, if the partition or volume on which the system + was initialized runs out of space and cannot be extended logically + or otherwise, a tablespace can be created on a different partition + and used until the system can be reconfigured. + + + + Secondly, tablespaces allow a database administrator to determine where + data should reside based on the usage patterns of database objects. For + example, an index which is very heavily used can be placed on very fast, + highly available disk, such as an expensive solid state device. At the same + time a table storing archived data which is rarely used or not performance + critical could be stored on a less expensive, slower disk system. + + + + Databases, schemas, tables, indexes and sequences can all be associated + with a tablespace. To do so, a user with the CREATE + privilege on a given tablespace must pass the tablespace name as a + parameter to the relevant command. For example, the following creates + a table in the tablespace + space1: + + CREATE TABLE foo(i int) TABLESPACE space1; + + + + + Two tablespaces are automatically created by initdb. The + global tablespace is used for shared system catalogs. The + default tablespace is used when a database is created without + reference to a tablespace. + + + + When a schema, table, index or sequence is created without a tablespace + parameter, the object inherits its logical parent's tablespace. A schema + will be created in the current database's tablespace; a table or sequence + will be + created in the tablespace of the schema it is being created in; + an index will be created in the tablespace of the table underlying the + index. Serial columns are created in the tablespace of the parent + table (See also ). + + + + Once created, a tablespace can be used from any database, provided + the given user has sufficient privilege. This means that a tablespace + cannot be dropped until all objects in all databases using the tablespace + have been removed. + + + + To simplify the implementation of tablespaces, + PostgreSQL makes extensive use of symbolic links. This + means that tablespaces can only be used on systems + which support symbolic links. + + + + The directory $PGDATA/pg_tablespaces contains two or more + symbolic links which point to the tablespaces defined in the system. + Although symbolic links are being used, modifying the location pointed + to by the link, even when the postmaster is not running, may + result in undefined behaviour. In particular, pg_dump will + not dump the new tablespace location. + + Index: doc/src/sgml/ref/postmaster.sgml =================================================================== RCS file: /usr/local/cvsroot/pgsql-server/doc/src/sgml/ref/postmaster.sgml,v retrieving revision 1.49 diff -2 -c -r1.49 postmaster.sgml *** doc/src/sgml/ref/postmaster.sgml 23 Mar 2004 06:09:00 -0000 1.49 --- doc/src/sgml/ref/postmaster.sgml 19 Jun 2004 11:17:48 -0000 *************** *** 417,433 **** - - - others - - - - Other environment variables may be used to designate alternative - data storage locations. See for more - information. - - - - --- 417,420 ----