Re: Big 7.1 open items

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 #