> > What are the plans for Postgres tablespaces?
>
> Well, what I envision is only a cleaner reimplementation of the
> existing LOCATION facility: the DBA will be able to designate
> certain directories as tablespaces and then assign individual
> tables, indexes, etc to particular tablespaces. Presumably, the DBA
> places each tablespace directory on a different disk (otherwise
> there's not much point in the exercise), and then the arrangement
> lets him control what lives where.
I'm reaching back four years now, but I found a very viable use for
extents and table spaces (albeit Oracle's implementation and interface
really blew):
1) extents - appending/writing to already allocated, zero'ed out data
allowed for significantly faster inserts (don't know if this is
really the case or not, or if it's still valid, but that was the
Gospel for the time)
2) extents in table spaces - were invaluable when creating cyclical
data tables. For example: in a table space, allocate extents 8
extents (each extent big enough for the day's worth of data - an
extent being pre-allocated disk space), then with a stored
procedure/rule, each day had its data inserted into an extent. On
the 8th day, drop the oldest extent, reformat the extent, then
re-add the extent to the table space: instant daily truncation
without having to do a delete on 200M rows. Being able to do this
was immensely useful for time driven cyclical data structures (25
extents for the daily data, 8 extents for the weekly data, 32
extents for the monthly data, 5 extents for the quarterly data,
etc.).
Hrm, now that I think about it, I suppose this could be done with
tables instead of extents and a view on top of them... ::ponders::
-sc
--
Sean Chittenden
