[
https://issues.apache.org/jira/browse/DERBY-4050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Matrigali updated DERBY-4050:
----------------------------------
note - the column is NUMUNFILLEDPAGES pages not NUMFILLED. See below for
comments from the diag SpaceTable javadoc about what the fields mean.
<P>The SpaceTable virtual table has the following columns:
<UL>
<LI>CONGLOMERATENAME varchar(128) - nullable. The name of the conglomerate,
which is either the table name or the index name. (Unlike the
SYSCONGLOMERATES column of the same name, table ID's do not appear
here).</LI>
<LI>ISINDEX SMALLINT - not nullable. Is not zero if the conglomerate is an
index, 0 otherwise.</LI>
<LI>NUMALLOCATEDPAGES bigint - not nullable. The number of pages actively
linked into the table. The total number of pages in the file is the
sum of NUMALLOCATEDPAGES + NUMFREEPAGES.</LI>
<LI>NUMFREEPAGES bigint - not nullable. The number of free pages that
belong to the table. When a new page is to be linked into the table the
system will move a page from the NUMFREEPAGES list to the NUMALLOCATEDPAGES
list. The total number of pages in the file is the sum of
NUMALLOCATEDPAGES + NUMFREEPAGES.</LI>
<LI>NUMUNFILLEDPAGES bigint - not nullable. The number of unfilled pages
that belong to the table. Unfilled pages are allocated pages that are not
completely full. Note that the number of unfilled pages is an estimate and
is not exact. Running the same query twice can give different results on
this column. </LI>
<LI>PAGESIZE integer - not nullable. The size of the page in bytes for
that conglomerate.
</LI>
<LI>ESTIMSPACESAVING bigint - not nullable. The estimated space which
could possibly be saved by compressing the conglomerate, in bytes.</LI>
</UL>
> Multithreaded clob update causes growth in table that does not get reclaimed
> ----------------------------------------------------------------------------
>
> Key: DERBY-4050
> URL: https://issues.apache.org/jira/browse/DERBY-4050
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.2.2.0, 10.3.3.0, 10.4.2.0, 10.5.0.0
> Reporter: Kathey Marsden
> Attachments: ClobGrowth.java, derby.log.growth, derby.log.nogrowth
>
>
> Doing a multithreaded update of a Clob table causes table growth that does
> not get reclaimed except by compressing the table. The reproduction has a
> table with two threads. One thread updates row 1 repeatedly with 33,000
> character clob. The other thread updates row 2 with a small clob, "hello".
> The problem occurs back to 10.2 but seems much worse on trunk than 10.2.
> The trunk database grew to 273MB on trunk after 10000 updates of each row.
> The 10.2 database grew only to 25MB. If the update is synchronized there is
> no growth.
> I will attach the repro.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
