db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: How to update cardinality statistics
Date Wed, 19 Oct 2005 18:28:32 GMT
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 <mikem_app@sbcglobal.net> 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.  

View raw message