Re: Physical Database Configuration

From: Fernando Schapachnik <fernando(at)mecon(dot)gov(dot)ar>
To: nolan(at)celery(dot)tssi(dot)com
Cc: shridhar_daithankar(at)persistent(dot)co(dot)in, pgsql-general(at)postgresql(dot)org, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Physical Database Configuration
Date: 2003-06-25 16:13:14
Message-ID: 20030625161314.GK318@bal740r0.mecon.gov.ar
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-hackers

En un mensaje anterior, nolan(at)celery(dot)tssi(dot)com escribió:
> > Well, correct solution is to implement tablespaces on which objects like
> > databases, tables and indexes can be put.
>
> I've not looked at the SQL standard, but it seems to me like the order
> should be:
>
> Databases
> Tablespaces
> Schemas
> Objects (tables, indexes, functions, etc.)
>

I'm not well versed in the SQL standard here, so maybe this is plain wrong, but
I think it would be nice to have some kind of separation between the logical
structure of the table (developer concern) and the physical disposition (DBA
concern), unlike what Oracle does (CREATE TABLE ... TABLESPACE ... OTHER
PHYSICAL PARAMETERS HERE).

Maybe a way is having storage classes:

CREATE TABLE ... STORAGE CLASS <name>.
STORAGE CLASS <name> TABLESPACE ...

Example of use:

Developer:

CREATE TABLE a (...) STORAGE CLASS big_tuples;
CREATE TABLE b (...) STORAGE CLASS heavy_use;

DBA:

STORAGE CLASS big_tuples TABLESPACE x;
STORAGE CLASS heavy_use TABLESPACE y;

Regards.

Fernando.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2003-06-25 16:22:27 Re: Inherits tables and current CVS
Previous Message johnnnnnn 2003-06-25 16:10:22 Re: [GENERAL] Physical Database Configuration

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2003-06-25 16:15:15 Re: compile warnings
Previous Message Rod Taylor 2003-06-25 16:12:18 Re: ECPG compile error