In RAID era tablespaces are not such important regarding performance.
But for backup/restore - the ability to backup/restore selected tablespaces
while leaving other tablespaces is a big thing.
The whole point here is: it is assumed that backup/restore of tablespaces can
hapen quite quickly and as simple as to copy tablespace files from one
location to another(even while database is on - WAL can be used to handle
this) - this is compared to dump.
For example, index, tempoarary data tablespaces can be lost - not a big deal.
Undo(rollback) tablespaces - in a way can be lost as well.
While system data tablespace (table structure, stored procedures, etc) - at
no cost should be lost.
The same way application can be devided in "critical" and "not critical"
tablespaces and their backups maintained accordingly. For example, it may not
be a big deal to lose year 1996 tables while year 2004 tables should be
online.
Laimis
> -----Original Message-----
> From: pgsql-general-owner@postgresql.org
> [mailto:pgsql-general-owner@postgresql.org] On Behalf Of Brian Maguire
> Sent: 21. janúar 2004 16:06
> To: pgsql-general@postgresql.org
> Subject: [GENERAL] tablespaces a priority for 7.5?
>
>
> Is support for tablespaces a priority feature for 7.5? I
> believe there has been significant development in this area
> and it seems that postgres' file structure opens it up nicely
> to support it. What are the chances this will be completed?
>
> In my opinion, it really is a critical feature to support and
> administer enterprise databases. All the major databases
> currently support this and it is a compelling enough reason
> drive big users from away from using postgres for their
> enterprise/large databases. It really is a database
> administrator's feature.
>
>
> Brian
>
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
http://archives.postgresql.org