db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3479) Changed/unexpected query plan when running test 'lang/predicatePushdown.sql'
Date Wed, 05 Mar 2008 18:07:41 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12575441#action_12575441

A B commented on DERBY-3479:

> I noticed that other tests that depend on stable query plans (wisconsin and StalePlansTest)
> set derby.storage.checkpointInterval=100000.

This is an interesting observation.  When I read it I assumed that this number was greater
than the default and that by setting it we were avoiding checkpoints.  But it turns out that
the opposite is true: the default checkpoint interval is 10*1024*1024, while 100000 is the
*minimum* checkpoint interval allowed (see raw/LogToFile.java).  With the default interval
we will not do any checkpoints during the running of predicatePushdown.sql; but with the minimum
interval of 100000, we do THREE checkpoints (at least on my machine).

So I wonder if the checkpoint does something which updates the row counts and/or statistics
for the tables, thus affecting the optimizer's decisions?  I have no idea what the answer
to that might be...

> Perhaps changing the concurrency/timing in the buffer manager somehow changes when
> the row count is flushed

While scanning LogToFile.java for the default checkpoint interval, I noticed the following:

        // setup checkpoint daemon and cache cleaner
        checkpointDaemon = rawStoreFactory.getDaemon();
        if (checkpointDaemon != null)
            myClientNumber =
                checkpointDaemon.subscribe(this, true /*onDemandOnly */);

            // use the same daemon for the cache cleaner

Note how the *same* daemon service is used for checkpointing and for cleaning the cache. 
The call to "setupCacheCleaner" ultimately ends up at CacheManager.java, which was modified
by DERBY-2911.  So I wonder if this daemon "sharing" could explain a) why a different cache
manager has an effect on predicatePushdown.sql, and/or b) why changing the checkpoint interval
seems to alleviate the effect?

Not sure if that's useful info or not, as I'm completely out of my knowledge base here.  But
I thought I'd mention it.

In the meantime, do you think it would be worth it set checkpointInterval to 100000 to see
if that gets predicatePushdown passing in the tinderbox again?

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

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message