You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Mike Matrigali <mi...@sbcglobal.net> on 2011/03/12 00:59:28 UTC
opinions on a less aggressive release of the istats feature?
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.
2)disable by default in all soft upgraded databases. This means that
applications not upgrading don't get a surprise background task.
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.
Re: opinions on a less aggressive release of the istats feature?
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 3/11/2011 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 think this is a possible solution in the 10.8 branch if the release
cannot wait for a fix for DERBY-5108. Are there other issues that the
community should be worried about or testing that you think should be
done before enabling by default? If we disable for 10.8.1, I think it
might be ok to turn it on for 10.8.2 if we feel it is rock solid at that
time with little risk of regression.
> 2)disable by default in all soft upgraded databases. This means that
> applications not upgrading don't get a surprise background task.
>
I think disabling just in soft upgrade mode wouldn't be good. The way
soft upgrade is typically used to test and stress the new version with
an application before making the commitment to full upgrade. If the
impact does not come until after full upgrade, then it is too late to
go back. I would prefer where possible to keep the risk exposure in
soft upgrade where there is still an exit strategy for users.
Re: opinions on a less aggressive release of the istats feature?
Posted by Rick Hillegas <ri...@oracle.com>.
On 3/14/11 11:02 AM, Mike Matrigali wrote:
> Given the limited feedback so far I don't think we should consider
> the soft upgrade option. I would prefer first release with istat
> defaulted off, but would not vote -1 if community thinks it is better
> with it defaulted on.
Based on the amount of hesitation expressed about running istat by
default, I turned it off by default as of revision 1081416 (see DERBY-5131).
>
> I also wanted to say that I do think the istat feature is a good one,
> and what I am most concerned about is not bugs in istat.
My impression is that the code is pretty solid.
> I am worried
> about application impact of istat doing what it is designed to do, run
> work in background. I just don't have a good feel whether defaulting
> it on will cause problems in existing applications.
I think that it will unquestionably cause problems for some
applications. I do not see how it couldn't. When you turn on this
feature, a read-intensive thread is going to crop up from time to time.
In certain environments, it is bound to have performance impacts.
Moreover, the behavior will be event-driven and therefore hard to
predict. An existing application may regard this performance drag as a
regression, particularly if the application has already coded its own
workaround to the problem of Derby statistics skew.
On the other hand, statistics skew is a real problem for even modestly
sized, shrink wrapped, embedded Derby apps. I don't see a lot of
workarounds:
a) Code your own version of istat to periodically measure the freshness
of your statistics and regenerate them if necessary. If you are lucky
and your application enjoys regular offline periods, then your customers
may never experience the istat drag.
b) Add a button to your app with this mouseover: "Push me if you
experience sluggish performance. This might help."
c) Hire a DBA for your 0-admin app.
> Also once we
> release with it defaulted on, I think it is harder to change this
> in the future.
Possibly so.
> If apache supported betas, it would be great to release
> this defaulted on.
Right. We don't have much luck when we appeal to our user community for
this kind of feedback. If you are worried about your own high profile
customers, you may be able to devise an in-house beta program.
I feel more comfortable about istat=on as the default for new
applications than as the default for old ones. Unfortunately, we have no
way of knowing whether an application is new or old--even old
applications create new databases and old databases can be re-used by
new apps.
My sense is that istat=on is the correct out-of-the-box experience,
while istat=off is a nice advanced feature for apps which enjoy low
intensity periods. But maybe my sense is merely idiosyncratic, based on
anecdotal evidence.
Thanks for pushing the discussion forward,
-Rick
>
>
Re: opinions on a less aggressive release of the istats feature?
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Given the limited feedback so far I don't think we should consider
the soft upgrade option. I would prefer first release with istat
defaulted off, but would not vote -1 if community thinks it is better
with it defaulted on.
I also wanted to say that I do think the istat feature is a good one,
and what I am most concerned about is not bugs in istat. I am worried
about application impact of istat doing what it is designed to do, run
work in background. I just don't have a good feel whether defaulting
it on will cause problems in existing applications. Also once we
release with it defaulted on, I think it is harder to change this
in the future. If apache supported betas, it would be great to release
this defaulted on.
Re: opinions on a less aggressive release of the istats feature?
Posted by Rick Hillegas <ri...@oracle.com>.
As Myrna notes, the consensus seems to be to re-enable istat=on as the
default Derby behavior. I have done this at subversion revision 1082671.
Thanks to everyone who responded,
-Rick
Re: opinions on a less aggressive release of the istats feature?
Posted by Myrna van Lunteren <m....@gmail.com>.
On Thu, Mar 17, 2011 at 10:23 AM, Dag H. Wanvik <da...@oracle.com> wrote:
> Lily Wei <li...@gmail.com> writes:
>
>> We had a fix for DERBY-5108 in the trunk and most of the running result
>> looks good to me with istate daemon on. My opinion is leaning toward to turn
>> the default to on for istat daemon. With it on, Derby is still zero-admin
>> db. Most users shouldn't know it is there. And, disable it is very easy
>> process for users. With the original seven days period to see how things are
>> going, we still have time to see the outcome if we turn the default to on.
>
> After having reviewed what's been happening in my absence, I'll give my
> 0.02 cents, too.
>
> The con is mostly that the feature hasn't been enabled on trunk for very
> long, and we have seen a few issues around it, although they have been
> mostly fixed. The file deletion issues on Windows (DERBY-5108) is not
> confined to this issue and something we need to fix going forward, by
> looking again at how we perform an orderly shutdown. It seems we have
> ordering problems there, cf [1], DERBY-4920 and Knut's observation on
> DERBY-5108 when calling SYSCS_UPDATE_STATISTICS on a large index just
> before shutting down the database.
>
> [1] https://issues.apache.org/jira/browse/DERBY-5108?focusedCommentId=13006941&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13006941
>
> On the other hand, I think this feature is a great one for a new
> release, and it would be sad to have to give it up. I'd rather be
> aggressive now, and get coverage for it in a new release as soon as we
> can. There will always be risk attached to a new feature, but this one
> can be disabled if necessary, and I agree it is definitely a step
> towards our aim of being a zero admin db.
>
> In this case I think the open source mantra of relasing early and often
> is pertinent. Let's get in the hands of users, with suitable warnings in
> the release notes, so we can get the feedback, if any, sooner rather
> than later.
>
> +0.75 to enable.
>
> Dag
>
Sounds like we're leaning toward switching it back on. Rick, do you
want to handle this (as you switched it off)? or are you opposed
and/or need help? I think we should put it in sooner rather than
later...
Myrna
Re: opinions on a less aggressive release of the istats feature?
Posted by "Dag H. Wanvik" <da...@oracle.com>.
Lily Wei <li...@gmail.com> writes:
> We had a fix for DERBY-5108 in the trunk and most of the running result
> looks good to me with istate daemon on. My opinion is leaning toward to turn
> the default to on for istat daemon. With it on, Derby is still zero-admin
> db. Most users shouldn't know it is there. And, disable it is very easy
> process for users. With the original seven days period to see how things are
> going, we still have time to see the outcome if we turn the default to on.
After having reviewed what's been happening in my absence, I'll give my
0.02 cents, too.
The con is mostly that the feature hasn't been enabled on trunk for very
long, and we have seen a few issues around it, although they have been
mostly fixed. The file deletion issues on Windows (DERBY-5108) is not
confined to this issue and something we need to fix going forward, by
looking again at how we perform an orderly shutdown. It seems we have
ordering problems there, cf [1], DERBY-4920 and Knut's observation on
DERBY-5108 when calling SYSCS_UPDATE_STATISTICS on a large index just
before shutting down the database.
[1] https://issues.apache.org/jira/browse/DERBY-5108?focusedCommentId=13006941&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13006941
On the other hand, I think this feature is a great one for a new
release, and it would be sad to have to give it up. I'd rather be
aggressive now, and get coverage for it in a new release as soon as we
can. There will always be risk attached to a new feature, but this one
can be disabled if necessary, and I agree it is definitely a step
towards our aim of being a zero admin db.
In this case I think the open source mantra of relasing early and often
is pertinent. Let's get in the hands of users, with suitable warnings in
the release notes, so we can get the feedback, if any, sooner rather
than later.
+0.75 to enable.
Dag
Re: opinions on a less aggressive release of the istats feature?
Posted by Lily Wei <li...@gmail.com>.
On Wed, Mar 16, 2011 at 12:42 PM, Knut Anders Hatlen <knut.hatlen@oracle.com
> wrote:
> Mike Matrigali <mi...@sbcglobal.net> writes:
>
> > My main concern has always been just the background work affecting
> > existing applications. At this point I have been convinced that default
> > on is in keeping with the zero admin goal, and that we have a workaround
> > easily implemented in the field if there are problems. So if we are
> > going to enable this enventually
> > I would much rather do it in the first release, rather than a subsequent
> > point release.
>
> I agree that turning it on by default does sound right for a zero-admin
> db. And since we believe that it won't cause any serious problems in its
> current state, I'm fine with enabling it. Most users shouldn't even
> notice that it's there, and those who do can easily disable it, as
> documented in the release notes. Hopefully they'll also file bug reports
> about problems they encounter, so that we can improve it further in
> later releases.
We had a fix for DERBY-5108 in the trunk and most of the running result
looks good to me with istate daemon on. My opinion is leaning toward to turn
the default to on for istat daemon. With it on, Derby is still zero-admin
db. Most users shouldn't know it is there. And, disable it is very easy
process for users. With the original seven days period to see how things are
going, we still have time to see the outcome if we turn the default to on.
Thanks and hope this help,
Lily
Re: opinions on a less aggressive release of the istats feature?
Posted by Knut Anders Hatlen <kn...@oracle.com>.
Mike Matrigali <mi...@sbcglobal.net> writes:
> My main concern has always been just the background work affecting
> existing applications. At this point I have been convinced that default
> on is in keeping with the zero admin goal, and that we have a workaround
> easily implemented in the field if there are problems. So if we are
> going to enable this enventually
> I would much rather do it in the first release, rather than a subsequent
> point release.
I agree that turning it on by default does sound right for a zero-admin
db. And since we believe that it won't cause any serious problems in its
current state, I'm fine with enabling it. Most users shouldn't even
notice that it's there, and those who do can easily disable it, as
documented in the release notes. Hopefully they'll also file bug reports
about problems they encounter, so that we can improve it further in
later releases.
But it's getting very close to the RC, and if the release manager thinks
it's too risky to reintroduce it at this point, I'm fine with that too.
--
Knut Anders
Re: opinions on a less aggressive release of the istats feature?
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Rick Hillegas wrote:
> I'm agnostic about this question. But I would like to hear more opinions
> before changing the default again. In particular, I want to hear Mike's
> opinion, because it is his hesitation which gave rise to this email thread.
I brought up the thread looking for a discussion (and I was not sure how
long it would take to fix DERBY-5108). My take from the limited
discussion is that the consensus is that the eventual default for istat
is to be enabled.
Given that consensus and if we don't see problems in all of our nightly
tests across jvm's/platforms running with istat enabled and with the fix
for DERBY-5108 checked
in I would rather see the first release of 10.8 include this enabled. I
would also like to hear/defer to Kristian's opinion on this. I've
reviewed the istat code itself, and with the new shutdown changes don't
know any problems in the code.
Unfortunately the only way to get the testing is to enable it in trunk,
and see.
My main concern has always been just the background work affecting
existing applications. At this point I have been convinced that default
on is in keeping with the zero admin goal, and that we have a workaround
easily implemented in the field if there are problems. So if we are
going to enable this enventually
I would much rather do it in the first release, rather than a subsequent
point release.
Today I am running a 100 iterations of the stat test in the environment
that previously failed every time, and will post the results to
DERBY-5108 later today.
>
> Thanks,
> -Rick
>
> On 3/16/11 11:00 AM, Kathey Marsden wrote:
>> On 3/16/2011 10:57 AM, Myrna van Lunteren wrote:
>>>
>>> Looking back over the last week or so, now that there's a probable fix
>>> for DERBY-5108, I'm inclined to actually opt for 3). I think it would
>>> be better to have this on by default.
>>> Making a 10.8 release with it off by default and then on again for a
>>> possible 10.8.2 sounds worse.
>>>
>>> I'd like opinions about having istat on by default soon (today?) and
>>> then giving the tests 3 days before cutting a release.
>>>
>> +1 Let's give the fix for DERBY--5108 a chance! Since istat was
>> disabled right about the same time we haven't seen how much difference
>> it will make. Turn it on today and then make the RC Monday sounds good.
>>
>>
>>
>>
>
>
Re: opinions on a less aggressive release of the istats feature?
Posted by Rick Hillegas <ri...@oracle.com>.
I'm agnostic about this question. But I would like to hear more opinions
before changing the default again. In particular, I want to hear Mike's
opinion, because it is his hesitation which gave rise to this email thread.
Thanks,
-Rick
On 3/16/11 11:00 AM, Kathey Marsden wrote:
> On 3/16/2011 10:57 AM, Myrna van Lunteren wrote:
>>
>> Looking back over the last week or so, now that there's a probable fix
>> for DERBY-5108, I'm inclined to actually opt for 3). I think it would
>> be better to have this on by default.
>> Making a 10.8 release with it off by default and then on again for a
>> possible 10.8.2 sounds worse.
>>
>> I'd like opinions about having istat on by default soon (today?) and
>> then giving the tests 3 days before cutting a release.
>>
> +1 Let's give the fix for DERBY--5108 a chance! Since istat was
> disabled right about the same time we haven't seen how much difference
> it will make. Turn it on today and then make the RC Monday sounds good.
>
>
>
>
Re: opinions on a less aggressive release of the istats feature?
Posted by Kathey Marsden <km...@sbcglobal.net>.
On 3/16/2011 10:57 AM, Myrna van Lunteren wrote:
>
> Looking back over the last week or so, now that there's a probable fix
> for DERBY-5108, I'm inclined to actually opt for 3). I think it would
> be better to have this on by default.
> Making a 10.8 release with it off by default and then on again for a
> possible 10.8.2 sounds worse.
>
> I'd like opinions about having istat on by default soon (today?) and
> then giving the tests 3 days before cutting a release.
>
+1 Let's give the fix for DERBY--5108 a chance! Since istat was disabled
right about the same time we haven't seen how much difference it will
make. Turn it on today and then make the RC Monday sounds good.
Re: opinions on a less aggressive release of the istats feature?
Posted by Myrna van Lunteren <m....@gmail.com>.
[...]
> -----Original Message-----
> From: Rick Hillegas [mailto:rick.hillegas@oracle.com]
> Sent: Monday, March 14, 2011 8:45 AM
> To: derby-dev@db.apache.org
> Subject: Re: opinions on a less aggressive release of the istats feature?
>
> 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
>>>
[...]
Looking back over the last week or so, now that there's a probable fix
for DERBY-5108, I'm inclined to actually opt for 3). I think it would
be better to have this on by default.
Making a 10.8 release with it off by default and then on again for a
possible 10.8.2 sounds worse.
I'd like opinions about having istat on by default soon (today?) and
then giving the tests 3 days before cutting a release.
Myrna
RE: opinions on a less aggressive release of the istats feature?
Posted by "Bergquist, Brett" <BB...@canoga.com>.
Just from the peanut gallery, this new "istat" feature will be greatly appreciated when available. At least from me it will be ;) It is the one thing missing for a truly "no dba" system.
We have a system installed that provisions and measures network performance for a large wireless communications vendor that runs 24/7 getting multiple millions of updates per day and having up to date statistics for the query and reporting features is essential as that data is always changing. This system does not have anyone watching it from a dba point of view so it has to be pretty much self maintaining.
So we are eagerly awaiting this new feature even if it is turned off by default!
Thanks so much for adding this feature.
Brett
-----Original Message-----
From: Rick Hillegas [mailto:rick.hillegas@oracle.com]
Sent: Monday, March 14, 2011 8:45 AM
To: derby-dev@db.apache.org
Subject: Re: opinions on a less aggressive release of the istats feature?
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.
>>
>
>
Re: opinions on a less aggressive release of the istats feature?
Posted by Rick Hillegas <ri...@oracle.com>.
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.
>>
>
>
Re: opinions on a less aggressive release of the istats feature?
Posted by Rick Hillegas <ri...@oracle.com>.
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.
>