>>>>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
>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
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 maximum size for that tablespace.
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
>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 :).
*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://www.cybertec.at>, kernel.cybertec.at <http://kernel.cybertec.at>
---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster