Re: Big 7.1 open items

Tom Lane wrote:
> JanWieck(at)t-online(dot)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 before a crash. Even
if using fsync() instead of fdatasync() (what we cannot use
at all and that's a pain from the performance PoV). 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(at)Yahoo(dot)com #