[
https://issues.apache.org/jira/browse/DERBY-4121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-4121:
----------------------------------
Actually given the code that knut posted it seems to only matter if you change
the number of unique values, or go from 0 to a non-zero number of rows. I knew
the stat code remembered
both numRows and numUnique - I didn't realize that we almost did nothing with
numRows.
Does anyone else think that the current way this number used is bad for a zero
admin db. It seems like we should be giving back very different information is
we run the stat gatherer and we find 1000 unique values and there were 1000
unique rows vs. 1000 unique values and 1,000,000 unique rows. If the
assumption is that in general we are not going to require user intervention to
gather stats what is a better guess :
1) as number of rows changes we won't change number of unique values
2) as number of rows changes the number of unique values will stay in the same
proportion
Obviously either assumption can be made wrong for a specific application, but
what would a good default assumption be. It seems option 1 is the current
default. I guess part of this question is what the resolve comment is
referring to as this is a much bigger deal the smaller the sample size and thus
the bigger the selectivity.
> Documentation: more UPDATE_STATISTICS fixes needed for Reference Manual and
> Tuning Derby
> ----------------------------------------------------------------------------------------
>
> Key: DERBY-4121
> URL: https://issues.apache.org/jira/browse/DERBY-4121
> Project: Derby
> Issue Type: Bug
> Components: Documentation
> Affects Versions: 10.5.0.0
> Reporter: Kim Haase
> Priority: Minor
>
> Kathey Marsden comments on DERBY-3787:
> Not a show stopper for the release, but in beginning my buddy testing,
> I noticed the examples should use CALL e.g.
> CALL SYSCS_UTIL.SYSCS_UPDATE_STATISTICS('SAMP','EMPLOYEE','PAY_DESC');
> CALL SYSCS_UTIL.SYSCS_UPDATE_STATISTICS('SAMP', 'EMPLOYEE', null);
> Also in the Tuning Guide under Working with Cardinality Statistics -> When
> Cardinality Statistics Go Stale we should refer users to the
> SYSCS_UTIL.SYSCS_UPDATE_STATISTICS stored procedure to update their
> statistics and cross reference the reference guide.
> Myrna van Lunteren suggests a new issue for this, so I'm filing it.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
