Would need to see the exact documentation reference, but this is not
the case. The storage system keeps an estimate of the number of
rows in a table. For performance reasons this estimate is not exact
(ie. we don't update a single could for every insert/delete/abort
insert/abort delete/commit). The actual update is tied to the time
pages move out of the cache. Because the number can drift there is
an optimization in the language execution engine that if it has just
executed a complete scan of the table then it updates the value
in the storage system.
But in almost all cases the automatic maintained row count maintained
by store is good enough and never needs to be updated. The scan
optimization is there to automatically catch the drift if it is
cheap to do so, it wasn't really meant for users to use to explicitly
update it (it was take advantage if a user happened to be executing
a complete scan for some other reason).
Øystein Grøvlen wrote:
"MM" == Mike Matrigali <[EMAIL PROTECTED]> writes:
MM> I 2nd Satheesh's query, it is useful to know why you care. Derby
MM> unlike most other database's automatically maintains histogram
MM> type information about the tables (this does require indexes to
MM> exist). This information is gathered directly from the indexes,
MM> and is automatically maintained by Derby.
MM> The row count is also automatically maintained by Derby - whether
MM> an index exists or not.
Sounds good, but I think read somewhere in the Derby documentation
that some statistical information was only updated when a query did a
sequential scan of the table.
