db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: initial page allocation versus incremental allocation
Date Wed, 04 Mar 2009 17:32:29 GMT
Whoever decides to work on this should do more than just document, as
these params are not tested.

They were added in the past for ad-hoc testing and performance 
debugging.  As has been suggested they were never fully 
implemented/documented as they did not fit in with the original goal
of the  product - ie. be a zero-admin embedded db for smaller devices.  The
idea, if they were used at all was for the software to automatically
determine what the best settings and up them dynamically rather than
force/allow user to do so.

As I remember the defaults have something to do with the following:
o Start with no preallocation as originally users actually would notice
if a 2k page table started out with 16k vs 2k for an empty table.
o default to 8 as again the "standard" user was space limited and did
not want to possibly waste space.
o 1000 is just a round number, but if it actually gets documented I 
would see if the code can actually support a number that is more than
the number of pages that can be tracked by a single allocation page (or
maybe 2).  This number is dependent on page sizes, so worst case would 
be allocation on a 2k page table.  Should just add some testing if it is 
to be supported.

Knut Anders Hatlen wrote:
> Brian Peterson <publicayers@verizon.net> writes:
> 
>> Won't this still limit the setting to the MAX_PRE_ALLOC_SIZE?  Why
>> have the maximum setting? Or, at least, why limit it to just 8 pages?
> 
> MAX_PRE_ALLOC_SIZE is 1000, it's the default that is just 8 pages, as
> far as I can see. (And no, I don't know why it is limited to 1000 pages,
> but I wouldn't expect many objections if a request to increase the limit
> was filed in JIRA - https://issues.apache.org/jira/browse/DERBY)
> 


Mime
View raw message