db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Date Wed, 07 Nov 2007 00:51:51 GMT
Stanley Bradbury wrote:
> Dan Karp wrote:
>> I think we may be getting hit with DERBY-269 (stale index cardinality 
>> causes table scans).  The command listed in that JIRA ("alter table 
>> <table-name> compress [sequential]") isn't valid.  Calling 
>> SYSCS_UTIL.SYSCS_COMPRESS_TABLE works, but takes a huge amount of CPU, 
>> disk I/O, and disk space.  Is there a simpler, straightforward way to 
>> force recalculation of these indexes?
>> https://issues.apache.org/jira/browse/DERBY-269
> According to the documentation: Cardinality statistics are updated when 
> a table scan is performed so a " select * from <table> " should do it.
can you point out this in the documentation, it sounds wrong.  We do 
update that stat that is the number of the rows in the table, but we 
don't update what I usually refer to as the cardinality stats - ie. the 
stats on the average number of duplicates per key value.  This requires
some sort of "ordered" scan with extra processing during the scan to
compare each row to it's neighbor and would add too much processing for
a scan.

View raw message