db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein.Grov...@Sun.COM (Øystein Grøvlen)
Subject Re: [jira] Created: (DERBY-510) DERBY-132 resolved ? Table not automatically compressed
Date Wed, 17 Aug 2005 13:07:36 GMT
>>>>> "MM" == Mike Matrigali <mikem_app@sbcglobal.net> writes:

    MM> Full compression of derby tables is not done automatically, I
    MM> am looking for input on how to schedule such an operation.  An
    MM> operation like this is going to have a large cpu, i/o, and
    MM> possible temporary disk space impact on the rest of the server.
    MM> As a zero admin db I think we should figure out some way to
    MM> do this automatically, but I think there are a number of
    MM> applications which would not be happy with such a performance
    MM> impact not under their control.

Ideally, one should be able to do such maintenance tasks
incrementally.  That way, one could interrupt a table compressions
when the user load is high and resume at a later time.  One could use
a low-priority thread for such tasks.

    MM> My initial thoughts are to pick a default time frame, say
    MM> once every 30 days to check for table level events like
    MM> compression and statistics generation and then execute the operations
    MM> at low priority.  Also add some sort of parameter so that
    MM> applications could disable the automatic background jobs.

Once every thirty days seems very seldom to me.

    MM> Note that derby does automatically reclaim space from deletes
    MM> for subsequent inserts, but the granularity currently is at
    MM> a page level.  So deleting every 3rd or 5th row is the worst
    MM> case behavior.  The page level decision was a tradeoff as
    MM> reclaiming the space is time consuming so did not want to
    MM> schedule to work on a row by row basis.  Currently we schedule
    MM> the work when all the rows on a page are marked deleted.

That an operation is more time consuming would not matter if it could
be done at times when the system is idle.  (Assuming that it is not so
time consuming that it is not possible to achieve sufficient
throughput. E.g., space is freed quciker than one is able to reclaim


View raw message