I also scratched my head for awhile, but it turns out unfortunately
compressing a 1 page heap will lead to a 2 page heap. The reason for
this is that compress takes advantage of the generic "bulk loading"
option which applies both to existing and newly created conglomerates,
originally this functionality was built for bulk import of data and then
used for ddl operations like compress which also load a bunch of data.
The main advantage is that no per row logging is necessary when this
is used. The code is not currently special cased for create a new
conglomerate and load it in same operation. So first the new
conglomerate is created and it gets 1 page which has some metadata on it
encoded in the first row on the page. Now for recovery to work right
for the "unlogged" load, load insures that all inserts only happen on
new pages and logs allocation of those new pages. So it first adds a
page to start the inserts and will add subsequent pages . If the load
aborts then the allocations are backed out but will leave the 1st page
untouched.
I will log an improvement request since it should be possible to use the
first page if you know table was created in same transaction as the
load. But it probably isn't that important as a usual user is not going
to run compress unless they have a lot of data. Also subsequent
transactions can insert on the 1st page so the space is not lost forever.
A B (JIRA) wrote:
[ https://issues.apache.org/jira/browse/DERBY-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575514#action_12575514 ]
A B commented on DERBY-3479:
----------------------------
Thanks for the insight, Knut. I don't know much about how it all works, but
your theory seems reasonable to me...for what very little that may be worth.
Aren't all of these tables so small that they should fit on a single page?
I would think so, at least for the first part of the test. I have no idea why
that's not the case--nor why compression appears to lead to an *extra* page...
I went ahead and committed d3479_1.diff with svn # 634064:
URL: http://svn.apache.org/viewvc?rev=634064&view=rev
If it turns out the extra page is undesirable and/or the change is not a good
one, then the commit can always be backed out.
Changed/unexpected query plan when running test 'lang/predicatePushdown.sql'
----------------------------------------------------------------------------
Key: DERBY-3479
URL: https://issues.apache.org/jira/browse/DERBY-3479
Project: Derby
Issue Type: Bug
Components: Regression Test Failure
Affects Versions: 10.4.0.0
Environment: OS: Solaris 10 6/06 s10x_u2wos_09a X86 64bits - SunOS 5.10
Generic_118855-14
JVM: Sun Microsystems Inc., java version "1.6.0_04", Java(TM) SE Runtime
Environment (build 1.6.0_04-b12), Java HotSpot(TM) Client VM (build 10.0-b19, mixed mode)
Reporter: Ole Solberg
Attachments: d3479_1.diff
Seen in tinderbox since r631930.
See e.g.
http://dbtg.thresher.com/derby/test/tinderbox_trunk16/jvm1.6/testing/testlog/SunOS-5.10_i86pc-i386/631932-derbyall_diff.txt
:
*** Start: predicatePushdown jdk1.6.0_04 derbyall:derbylang 2008-02-28 14:02:49
***
9285 del
< Rows seen from the left = 20
9285a9285
Rows seen from the left = 10
9297 del
< Rows seen from the right = 20
9297a9297
Rows seen from the right = 10
9299 del
< Rows returned = 20
9299a9299
Rows returned = 10
.
.
.
