No enthusiasm has been expressed for options (2) or (3). Knut pointed
out on DERBY-5108 that the shutdown problem also affects existing
applications which shutdown in the middle of running the
statistics-updating procedures. I think that istat-on-by-default
increases the risk that this problem will affect production
applications. I don't know how to measure that increased risk. I suppose
it could be significant.
I am going to pursue option (1), i.e., turn of istat by default. I
propose to do this on the trunk, run regression tests to verify that
everything looks good, let the nightlies vet the change, then cut the
branch tomorrow and re-enable istat on the trunk. I believe that turning
off istat involves the following steps. Does this sound right?
o Back out the changes which enabled the feature
(derby-4939-1a-enable_istat.diff). This means:
- Default Property.STORAGE_AUTO_INDEX_STATS=false in DataDictionaryImpl.
- Comment out the addition of AutomaticIndexStatisticsTest and
AutomaticIndexStatisticsMultiTest in the store JUnit suite.
o Regenerate the 10.8.1 release notes:
- Remove the summary line for this feature.
- Change the detailed note for DERBY-4939 so that it says that the
feature is disabled by default.
Thanks,
-Rick
On 3/11/11 4:26 PM, Rick Hillegas wrote:
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.
