Обсуждение: RE: [HACKERS] [hackers]development suggestion needed

>> > So, what's the deal, here...is the goal the Big Time or not?
>> 
>> If it means adopting one vendors concept of what the world should look
>> like...not.
>> 
>> I *hate* the way Oracle sets up tablespaces ... where i have to
>> pre-guess
>> the size of my data and allocate space accordingly...what if my table
>> never does reach that critical mass?  I've just wasted X meg of space
>> ...
I go with you on the size thing, but I still think it's not a bad idea to be
able to determine WHERE your data goes, at least down to a table/index/etc.
level.

>> I hate the way that Oracle starts up something like 4 processes for
>> every
>> database, when the server is started...
Well, Oracle doesn't see a database quite the way we do.  At least, not the
way we use it.  We tend to have multiple schemas in a single 'instance', or
database.  These schemas are actually defined per user.  This is possible on
Postgres, but people just don't do it.  So although four processes are
started for each instance, we only have two instances running on our main
dev server, even though there are about twenty-five schemas on it.

<snip>

>> If that happens to follow what one vendor happens to have done as far >>
as
>> their implementation, great...but there has been no conscious effort to
>> do
>> so that I'm aware of...
Cool.  PostgreSQL is a vendor.

>> Just look at the whole OUTER JOIN issue ... *shrug*
>> 
>> I *like* the fact that we come up with original ideas/solutions to
>> problems, that make use of *existing* technologies ...
And move to new technologies a lot quicker than any other product.

>> I liked the thread about moving indexes and tables to seperate file
>> systems, and hope we can implement something that will make it 
>> something
>> that does't require 'ln's, but I definitely don't like Oracle's way of
>> doing things ...
Yes, that's about the sum of it.  Why not the links?  I think that it's an
elegant way of designing the whole thing.  Only the system table that stores
the 'tablespace' directories will even have a hard path in it.  For the
rest, everything works in the main database directory (which could be
considered the SYSTEM tablespace).

MikeA

Then <Michael.Ansley@intec.co.za> spoke up and said:
> >> I liked the thread about moving indexes and tables to seperate file
> >> systems, and hope we can implement something that will make it 
> >> something
> >> that does't require 'ln's, but I definitely don't like Oracle's way of
> >> doing things ...
> Yes, that's about the sum of it.  Why not the links?  I think that it's an
> elegant way of designing the whole thing.  Only the system table that stores
> the 'tablespace' directories will even have a hard path in it.  For the
> rest, everything works in the main database directory (which could be
> considered the SYSTEM tablespace).

It seems to me (in spite of the fact that I contribute no code) that
we *might* want to consider if we want a system table that contains
storage manager specific information.  Our current storage manager
could probably be extended (with some small amount of difficulty) to
get more path information out of such a table.  A raw partition
storage manager might want pathing and sizeing information.

Back to the symlink stuff: symlinking in general should be deprecated
since it doesn't work everywhere, PLUS it causes ugliness in the table
truncation code.  I must admit, I'm and Ingres fan, and I kinda like
the way it does things (very similar to what PostgreSQL does, but
explicit pathing in a system table).  A database is created in a
default location, it can then be extended across multiple locations.
Without explicit instruction, however, it will create all new files in
the default location.  Ingres also has the initial database lookup
function return the default database area.

-- 
=====================================================================
| JAVA must have been developed in the wilds of West Virginia.      |
| After all, why else would it support only single inheritance??    |
=====================================================================
| Finger geek@cmu.edu for my public key.                            |
=====================================================================