db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <j...@apache.org>
Subject [jira] Updated: (DERBY-4121) Documentation: more UPDATE_STATISTICS fixes needed for Reference Manual and Tuning Derby
Date Wed, 01 Apr 2009 17:02:12 GMT

     [ 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.


Mime
View raw message