Re: Table spaces again [was Re: Threaded Sorting]

From: Hans-Jürgen Schönig <postgres(at)cybertec(dot)at>
To: shridhar_daithankar(at)persistent(dot)co(dot)in, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Table spaces again [was Re: Threaded Sorting]
Date: 2002-10-07 15:23:03
Message-ID: 3DA1A6D7.9020702@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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 maximum size 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>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Jim Buttafuoco 2002-10-07 15:29:35 Re: Table spaces again [was Re: Threaded Sorting]
Previous Message Manfred Koizar 2002-10-07 15:22:41 Re: Large databases, performance