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.
