db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-3479) Changed/unexpected query plan when running test 'lang/predicatePushdown.sql'
Date Wed, 05 Mar 2008 23:13:54 GMT
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

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:
>>         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
>> .
>> .
>> .

View raw message