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

>
>
>>>>Quotas are handled differently on ever platform (if available).
>>>>        
>>>>
>>>Yeah. But that's sysadmins responsibility not DBA's.
>>>      
>>>
>>Maybe many people ARE the sysadmins of their PostgreSQL box ...
>>When developing a database with an open mind people should try to see a 
>>problem from more than just one perspective.
>>Why should anybody just forget about sysdbas???
>>    
>>
>
>If DBA is sysadmin, does it make a difference if he learnes about mount/ln or 
>table spaces. Yes it does. Table spaces are limited to databases but mount/ln 
>is useful for any general purpose sysadmin work.
>
>That answers the last point as well, I guess..
>  
>

I agree but still, think of hybrid systems ..

>
>Agreed. Perfect point and I didn't thought of it.
>
>But it can be done in directory structure as well. Of course it's quite a 
>deviation from what one thinks as plain old directory structure. But if this is 
>one point where table spaces win, let's borrow that. There is lot of baggage in 
>table spaces that can be left out..
>
>Besides AFAIU, tablespaces implements quota using data files which are pre-
>allocated. Pre-claiming space/resource  is the evil of everything likes of 
>oracle do and runs in exact opposite direction of postgresql philosophy.
>
>If postgresql has to implement quotas on object, it should do without 
>preclaiming space.
>
>Besides if postgresql offers quota on per object basis in directory/object 
>scheme, I am sure that's far more granular than tablespaces. Choice is good..
> 
>
I didn't think of pre allocation - this is pretty much like Oracle would 
do it.
I was thinking of having a maximum size or something like that.
Overhead such as EXTENDS and things like that don't seem too useful for 
me - that's what a filesystem can be used for.

I agree with Tom: If a tablespace was a directory it would be pretty 
simple and pretty useful. If people could define a maximum size it would 
be more than perfect.
All I think is necessary is:   - having data in different, user defined, locations   - having the chance to define a
maximumsize for that tablespace.
 

Suggestion:
CREATE TABLESPACE: Create a "directory" with a certain size (optional) - 
nothing special here.
ALTER TABLESPACE: resize table space. resizing is possible if the amount 
of data in the tablespace < new size of tablespace
DROP TABLESPACE:  remove table space. the question in this case is - 
what about the objects in the tablespace?   objects can not always be deleted (just think of inheritance and 
parent tables)

>It's not about devil. It's about revaluating need once again. Especially at the 
>level of tablespace concept in itself.
>
>  
>

That's why people should discuss it and think about it :).
People want a good implementation or no implementation :).
This is Open Source - it is designed to be discussed :).
   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>