Re-sending this message because my mail server seems to have choked on it.
-------- Original Message --------
Subject: Delivery Notification
Date: Wed, 2 Mar 2011 12:50:28 -0800 (PST)
From: <[email protected]>
To: Rick Hillegas <[email protected]>
This is an automatically generated Delivery Status Notification.
Final-Recipient: rfc822;<[email protected]>
Diagnostic-Code: 5
Action: failed
Status: 5.0.0
--- Begin Message ---
Thanks for doing all this work while you are on paternity leave,
Kristian. A couple comments inline...
On 3/2/11 11:09 AM, Kristian Waagan wrote:
Hi,
The 10.8 release candidate will soon be created, and there are a few
remaining decisions to make regarding the new "istat feature"
(automatic update/creation of index cardinality statistics):
a) Documentation, see DERBY-5083 and comments under DERBY-5051.
b) Whether or not to enable logging by default, especially the
processing stats summary printed on database shutdown. See comment
under DERBY-5051.
c) Whether or not to increase the table row count thresholds for
statistics creation and update. These are currently 100 and 1000,
respectively.
I don't have many cycles to spend before the RC is cut, but here are
my thoughts:
a) Now that a release note has been written, we probably have the
minimum amount of documentation required. We probably don't want too
much documentation in the manual(s), since the functionality may
change based on user feedback from 10.8. As long as the user is told
how to disable the feature, I think we're good. If someone wants to
describe more of the feature, things like logging, tracing, and how
updates/creations are triggered may be good points to cover.
b) I see that Knut argued logging should be disabled by default in
the production code. That's fine with me, the only thing we may loose
[1] is basic information in the case of intermittent and rare scenarios.
I think Knut's arguments are reasonable.
c) Since the thresholds are set based on gut-feeling, we may want to
err on the side of caution instead of burning resources on generating
statistics without much gain. Assuming the update threshold (basically
the minimum number of rows in the table) is kept reasonably low, I
would set the creation threshold to the same value. The optimal value
would be when having more accurate statistics would make the optimizer
choose a significantly better plan. An always correct value may not
exist... Any suggestions?
I think we're basically talking about the difference between computing
the statistics once vs. twice for the first 1000 rows. Without any
compelling evidence that the current situation is broken I'd prefer to
leave the code alone now that we're very close to code-freeze.
Besides from these issues, I observe that one of the istat tests runs
into an OOME on Java 5.0 and 1.4 (DERBY-5057), one of the istat tests
fails on Windows due to problems deleting files [2], and one other
intermittent test failure (DERBY-5045).
Did I miss anything?
There is also DERBY-5082, a bad shutdown exception percolating out of
the istat daemon. I have marked this as a blocker for the release.
Thanks,
-Rick
Regards,
--- End Message ---
