db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: opinions on a less aggressive release of the istats feature?
Date Sat, 12 Mar 2011 00:26:14 GMT
On 3/11/11 3:59 PM, Mike Matrigali wrote:
> With the 10.8 release coming up quick and the istats feature put into
> trunk so recently I was wondering what the community would think about
> a less aggressive release of the feature.  No matter what I think it
> should stay enabled by default in trunk.
>
> 2 options I can think of are:
> 1)disable by default, allowing those users that want the feature
>   to enable it.
I am comfortable with this default. We can make the change to istat 
shutdown which you recommend on DERBY-5108 and then continue studying 
the behavior of this feature on the trunk. It would be disappointing if 
we had to wait another year before exposing istat-on-by-default. In the 
long run I think that is a better default for a 0-admin database. I 
would support a 10.9 release later this year (maybe even in a couple 
months) when we are more confident about this code.
> 2)disable by default in all soft upgraded databases.  This means that
>   applications not upgrading don't get a surprise background task.
I'm not keen on this approach. If the feature has shutdown-related 
problems, then that's a showstopper for it being the default in any 
configuration.

Another option would be:

3) Make the istat shutdown change you recommend and give the code a 
little while to earn our confidence. I would be willing to delay the 
release a week for this approach if we think that's enough time to make 
the change and build confidence. I do not want to push the release out 
further.

Thanks,
-Rick
>
> This decision would match other performance/resource decisions 
> implicitly being made for the system where I think a number of users
> would benefit with increased resource usage by Derby but think it
> would be bad to default the system.  These include:
> o page cache of 1000 can be as small as around 4 meg, which is 
> incredibly small in the world of 4-8 gig laptops.
> o sort memory defaults to a very small number currently.
> o we don't do aggressive background space reclamation which would add
>   background processing overhead that active apps might not want.
>


Mime
View raw message