db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (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.
Date Mon, 21 May 2012 22:19:41 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13280549#comment-13280549

Dag H. Wanvik commented on DERBY-3790:

Thanks, Kristian. The patch looks good to me. +1

Optional nits:

- in createindexconstantaction, the parameter to addStatistics is CardinalityCounter. This
makes the calling site have to redo the call CardinalityCounter#getRowCount.
  Might as well do that before the call to addStatistics and pass in the long, since CardinalityCounter
is not otherwise used inside addStatistics. This line could then be removed

  if (addStatistics(dd, indexRowGenerator, cCount))
       long numRows = cCount.getRowCount();  <------

  long numRows = cCount.getRowCount;
  if (addStatistics(dd, irg, numRows) {
     long[] c = cCount.getCardinality();

- The boolean tested  for dd version is sometimes negative: dbIsPre10_9, other times positive:
  This is slightly confusing. Maybe we should stick to a positive semantic, i.e. "10_9 or
newer"? It would also be more readable, e.g. here:

   // Skip single-column unique indexes unless we're told not to,
   // or we are running in soft-upgrade-mode on a pre 10.9 db.
   if (!dbIsPre10_9 && !FORCE_OLD_BEHAVIOR) {  <-- note negation !dbIsPre10

> Investigate if request for update statistics can be skipped for certain kind of indexes,
one instance may be unique indexes based on one column.
> ------------------------------------------------------------------------------------------------------------------------------------------------
>                 Key: DERBY-3790
>                 URL: https://issues.apache.org/jira/browse/DERBY-3790
>             Project: Derby
>          Issue Type: Improvement
>          Components: Store
>    Affects Versions:
>            Reporter: Mamta A. Satoor
>            Assignee: Kristian Waagan
>         Attachments: derby-3790-1a-skip_stats_scui.diff
> DERBY-269 provided a manual way to update the statisitcs. There was some discussion in
that jira entry for possibly optimizing the cases where there is no need to update the statistics.
I will enter the related comments from that jira entry here for reference.
> **************************
> Knut Anders Hatlen - 18/Jul/08 12:39 AM 
> If I have understood correctly, unique indexes always have up to date cardinality statistics
because cardinality == row count. If that's the case, one possible optimization is to skip
the unique indexes when SYSCS_UPDATE_STATISTICS is called. 
> **************************
> **************************
> Mike Matrigali - 18/Jul/08 09:48 AM 
> is the cardinality of a unique index 1 or is it row count? 
> It is also more complicated than just skipping unique indexes, it depends on the number
of columns in the index because 
> in a multi-column index, multiple cardinalities are calculated. So for instance on an
index on columns A,B,C there are 
> actually 3 cardinalities calculated: 
> A 
> A,B 
> A,B,C 
> I agree that the calculation of cardinality of A,B,C could/should be short circuited
for a unique index. 
> **************************
> **************************
> Knut Anders Hatlen - 18/Jul/08 03:25 PM 
> Mike, 
> It looks to me as if the cardinality is the number of unique values, so I think the cardinality
of a unique index is equal to its row count (for the full key, that is). You're right that
we can't short circuit it if we have a multi-column index. I don't know if it's worth the
extra complexity to short circuit the A,B,C case, since we'd have to scan the entire index
anyway. For a single-column unique index it sounds like a good idea, though. 
> **************************

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


View raw message