Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <450430556.1242999885953.JavaMail.jira@brutus>
Date: Fri, 22 May 2009 06:44:45 -0700 (PDT)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Commented: (DERBY-4233) Lower tablescan performance right
 after database creation in 10.5
In-Reply-To: <1362997583.1242642825551.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-4233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12712081#action_12712081 ] 

Knut Anders Hatlen commented on DERBY-4233:
-------------------------------------------

I haven't been able to find anything in the DERBY-3678 patch that
should be causing a performance regression, but I have managed to
identify which part of the patch that changes the performance. If the
call to ScanController.fetchNext() in
DataDictionaryImpl.getDescriptorViaIndexMinion() is changed back to
ScanController.next() + ScanController.fetch(), the performance goes
back to normal. I have no idea why, as the work performed by the two
is almost identical.

Some more observations: The throughput seems to vary between two
levels. In general, it tends to be at the higher level when running
without the 3678 patch and at the lower level when running with
it. But in some cases a run with the 3678 patch may have throughput at
the higher level, and vice versa without the patch.

Also, if the test reuses the database and the tables instead of
creating new ones, I see that the throughput is at an even higher
level, and the throughput is the same with and without the 3678
patch. This kind of makes sense, since the JVM uses statistics to
perform optimization, and it's more likely to make good decisions for
select statements if the statistics haven't been polluted by the
initial inserts.

> Lower tablescan performance right after database creation in 10.5
> -----------------------------------------------------------------
>
>                 Key: DERBY-4233
>                 URL: https://issues.apache.org/jira/browse/DERBY-4233
>             Project: Derby
>          Issue Type: Bug
>          Components: Performance, SQL
>    Affects Versions: 10.5.1.1
>         Environment: Solaris Express Community Edition snv_114 X86
> java version "1.6.0_13"
> Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
> Java HotSpot(TM) Server VM (build 11.3-b02, mixed mode)
>            Reporter: Knut Anders Hatlen
>
> I noticed that a table scan test performed significantly worse
> (10-20%) in Derby 10.5.1.1 than in Derby 10.4.2.0. I only see this if
> the test creates and populates a fresh database. To reproduce, put
> derbyTesting.jar from 10.5.1.1 and derby.jar from the release you want
> to test in your classpath, and execute the following shell commands:
> # make sure the database is removed so that we create a fresh one
> test -d db && rm -rf db
> # run test for five minutes (+ one minute warm-up)
> java -server -Dderby.storage.pageCacheSize=25000 \
>     org.apache.derbyTesting.perf.clients.Runner \
>     -load sr_select -load_opts nonIndexed -wt 60 -rt 300 -init

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