Tom Lane wrote:
> JanWieck@t-online.de (Jan Wieck) writes:
> > There are also disadvantages.
>
> > You can run out of space even if there are plenty GB's
> > free on your disks. You have to create tablespaces
> > explicitly.
>
> Not to mention the reverse: if I read this right, you have to suck
> up your GB's long in advance of actually needing them. That's OK
> for a machine that's dedicated to Oracle ... not so OK for smaller
> installations, playpens, etc.
Right, the design is perfect for a few databases with a more or less stable size and schema (slow to medium
growth). The problem is, that production databases tend to fall into that behaviour and that might be a reason
for so many people asking for Oracle compatibility - they want to do development in the high flexible Postgres
environment, while running their production server under Oracle :-(.
> I'm not convinced that there's anything fundamentally wrong with
> doing storage allocation in Unix files the way we have been.
>
> (At least not when we're sitting atop a well-done filesystem,
> which may leave the Linux folk out in the cold ;-).)
I'm with you on that, even if I'm one of the Linux loosers. The only point that really strikes me is that in
our system you might end up with a corrupted file system because some inode changes didn't make it to the disk
beforea crash. Even if using fsync() instead of fdatasync() (what we cannot use at all and that's a pain from the
performancePoV). In the Oracle world, that could only happen during
ALTER TABLESPACE <tsname> ADD DATAFILE ...
which is a fairly seldom command, issued usually by the DB admin (at least it requires admin privileges)
and thus ensures the "admin is there and already paying attention". A little detail not to underestimate IMHO.
Jan
--
#======================================================================#
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck@Yahoo.com #
