Thanks for the heads-up, Kristian. I will hold off generating the
release candidate until I get a green light from you that this work is done.
Thanks,
-Rick
On 5/16/12 9:19 AM, Kristian Waagan wrote:
On 15.05.12 20:17, Rick Hillegas wrote:
A little less than a week remains before we build the first 10.9 release
candidate. At the end of this message, I summarize the status of
important issues, which people had hoped we would address for 10.9.
At this time, I do not see any reason to push back the 10.9 schedule and
I plan to build a release candidate next Monday. Please let me know if
you disagree with this decision.
Hi Rick,
I'm planning to get some fixes in for update statistics functionality.
The current code has been posted on DERBY-5684, but it may be that I
break it up into a few parts. It will be a little tight, but I hope I
can complete this some time during Monday.
The fixes would address the following issues:
o DERBY-5680: indexStat daemon processing tables over an over even
when there are no changes in the tables ([1])
o DERBY-3790: Investigate if request for update statistics can be
skipped for certain kind of indexes, one instance may be unique
indexes based on one column.
In addition it would optimize how the statistics are generated for
single-column foreign keys backed by a unique index. In this case the
row estimate from the backing index will be used.
To reduce the risk of something going seriously wrong in the wild, I
will include a debug flag that allows people to fall back to the 10.8
behavior ([2]). Combined with the new SYSCS_DROP_STATISTICS system
procedure and the knob to disable the istat daemon, that will
hopefully be enough to work around any issues detected after the release.
The current code passes suites.All, and I've added an upgrade test.
Some adjustments are required for some of our existing tests, since
there will be fewer statistics entries for some tables.
Regards,
