I believe a full table scan updates the internal row count for that table but will not cause index cardinality (additional info) to be updated for each index on that table...
http://db.apache.org/derby/docs/10.3/tuning/ctunstats848901.html http://db.apache.org/derby/docs/dev/tuning/tuning-single.html#ctunstats46438 On Nov 6, 2007 4:13 PM, Stanley Bradbury <[EMAIL PROTECTED]> 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. > > >
