> ??? Mhm, there seems to be a big misunderstanding. > If you just specify ONE devspace with 100 000 pages, i.e. > tell the kernel DEVSPACE_NAME and DEVSPACE_SIZE, > then your database has not more than 100 000 pages, no matter > how many devspaces you COULD have specified. This > maximum number is given by MAXDEVSPACES.
Right, I understand that. The default for MAXDATAPAGES seems to be over a million though. So I would be limited to 10 devspaces. I put it at 100 because I'm lazy. > But the kernel is not able, not allowed (how should it do it?) > to say, 'ok, those pages whose number (100 000) I know and > of which I know the name of the devspace are full, lets create > a new file or raw device somewhere on the users disks, name it > somehow, specify a size I, the kernel, would like and fill it.' Ah, that is too bad. It would be nice because (say) I start with a database that is 25MB but grows to 2GB, but I have 50 GB of space? I should be able to say: divide yourself into chunks of 650MB (convenient size for burning CDs, or whatever) and extend yourself out as long as you don't top 50GB! :) > is full, the USER/ADMINISTRATOR of the database has to decide, where > and how much additional disk-space the database may use. I agree, but I should be able to specify something like the above: division size is (X) MB. total possible size is (X) MB. it should be that simple. I don't care about "data pages" that's a meaningless number to me. I need to know how this relates to the filesystem, and the above makes good sense. It is extremely minor, but still an important point. > Each table/index/meta-data of the database is allowed to be stored > at ANY devspace used for this database. It is spread over all devspaces I do understand that. I would be horrified if that was not the case :) > available. Therefore it does not matter if you have 50 devspaces > each with 100 000 pages or one huge devspace if you want to store a table > which will need much more than those 100 000 pages available on ONE small > devspace. Which is precisely why I think devspaces need only be defined in "chunk size" and "maximum size of all chunks" because the user doesn't actually care about anything else: the numbers are arbitrary so don't scare people with the thought that they might _not_ be arbitrary and somehow affect the performance of the database. I don't need to know that much. > Things are a little bit different to Oracle. In general, I think you have done a much better job than oracle, especially with the tools. Most things are clear and simple, which is what I like. In this case, though, I think Oracle handles storage definition in a more sensible way. minor point :) -alex _______________________________________________ sapdb.general mailing list [EMAIL PROTECTED] http://listserv.sap.com/mailman/listinfo/sapdb.general
