Re: Table spaces again [was Re: Threaded Sorting] - Mailing list pgsql-hackers

From Hans-Jürgen Schönig
Subject Re: Table spaces again [was Re: Threaded Sorting]
Date
Msg-id 3DA191B6.904@cybertec.at
Whole thread Raw
In response to Table spaces again [was Re: Threaded Sorting]  ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>)
Responses Re: Table spaces again [was Re: Threaded Sorting]  ("Shridhar Daithankar" <shridhar_daithankar@persistent.co.in>)
Re: Table spaces again [was Re: Threaded Sorting]  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
>
>
>Can anybody please tell me in detail.(Not just a pointing towards TODO items)
>
>1) What a table space supposed to offer?
>

They allow you to define a maximum amount of storage for a certain set 
of data.
They help you to define the location of data.
They help you to define how much data can be used by which ressource.

>2) What a directory structure does not offer that table space does?
>

You need to the command line in order to manage quotas - you might not 
want that.
Quotas are handled differently on ever platform (if available).
With tablespaces you can assign 30mb to use a, 120mb to user b etc. ...
Table spaces are a nice abstraction layer to the file system.

>
>3) How do they compare for advantages/disadvantages..
>
>Oracle familiarity is out. That's not even close to being good merit IMO. If 
>postgresql moves to oracle way of doing things, .. well, I won't be as much 
>hapy as I am now..
>
>Thanks for your patience..
>

how would you handle table spaces? just propose it to the hackers' list ...
we should definitely discuss that ...
a bad implementation of table spaces would be painful ...

   Hans

-- 
*Cybertec Geschwinde u Schoenig*
Ludo-Hartmannplatz 1/14, A-1160 Vienna, Austria
Tel: +43/1/913 68 09; +43/664/233 90 75
www.postgresql.at <http://www.postgresql.at>, cluster.postgresql.at 
<http://cluster.postgresql.at>, www.cybertec.at 
<http://www.cybertec.at>, kernel.cybertec.at <http://kernel.cybertec.at>




pgsql-hackers by date:

Previous
From: "Shridhar Daithankar"
Date:
Subject: Re: Implicit Lock Row
Next
From: Manfred Koizar
Date:
Subject: Re: [GENERAL] Large databases, performance