db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "A B (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1315) largeCodeGen fails with embedded and framework DerbyNetClient
Date Tue, 08 Aug 2006 20:38:14 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1315?page=comments#action_12426705 ] 
            
A B commented on DERBY-1315:
----------------------------

> - The scenario with SELECT with 10000 unions used to fail after compilation in 10.0 
>    and 10.1.2. But with 10.1.3 and 10.2 the statement fails during compile with OutOfMemory
error.

I hate to say it, but it looks like this regression is caused by the changes for DERBY-805.
  Before the DERBY-805 changes Derby was generating plans for subqueries that did not agree
with the optimizer's choices.  Phase 1 of the DERBY-805 patches made it so that Derby generates
the plans chosen by the optimizer, as one might expect.  In order to do that, I added extra
state to the optimizable nodes to keep track of which query plan went with which level of
query.

My guess is that this extra state is causing the optimizer to increase its memory usage--and
thus for very large queries, we end up running out of memory  This is backed by two things:
1) the changes for DERBY-805 apply specifically to UNIONs, and the query that's failing has
10,000 unions in it; 2) the DERBY-805 changes were checked into the 10.1.2.4 snapshot and
thus are part of 10.1.3--which explains the behavior quoted above from Rajesh.

I ran the repro with 512M against a version of the 10.1 jars that immediately precedes any
DERBY-805 check-ins and it "passes" (i.e. fails with linkage error); I then ran it against
another version that was created shortly after all of DERBY-805 was ported to 10.1; it fails
with OOM.

So there's the regression.

That said, it'll be virtually impossible for me to try to address this issue for the 10th--I'm
already booked with DERBY-1633 (the other regression...*sigh*).

Not sure where that leaves us.  Sorry.

> largeCodeGen fails with embedded and framework DerbyNetClient
> -------------------------------------------------------------
>
>                 Key: DERBY-1315
>                 URL: http://issues.apache.org/jira/browse/DERBY-1315
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.2.0.0
>         Environment: Linux - Suse 2.6.5-7.252
>            Reporter: Ramandeep Kaur
>            Priority: Minor
>         Attachments: 1315-comparison.html, largeCodeGen.java, largeCodeGen.out, largeCodeGen.sql,
largeCodeGen.tmp, largeCodeGen.tmpmstr
>
>
> The test case lang/largeCodeGen.java was run as is without giving any -Djvmflags="-mx512M
-ms512M" and gave the following error:
> *** Start: largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:30:04 ***
> 27a28
> > JVMST109: Insufficient space in Javaheap to satisfy allocation request
> Test Failed.
> *** End:   largeCodeGen jdk1.4.2 largeDataTests:largeDataTests 2006-04-29 08:32:01 ***
>  
> Then the test case lang/largeCodeGen.java was run with -Djvmflags="-mx512M -ms512M",
and it gave the following error:
> < PASS: IN clause with 97000 parameters
> 20 del
> < PASS: PREPARE: IN clause with 98000 parameters
> 21 del
> < PASS: IN clause with 98000 parameters
> 22 del
> < FAILED QUERY: IN clause with 99000 parameters. 
> 22a19
> > FAILED QUERY: IN clause with 97000 parameters.
> Test Failed.
> Then I modified test case lang/largeCodeGen.java to set PRINT_FAILURE_EXCEPTION  to true
and ran the test again. This time I got the following error and stack trace:
> MasterFileName = master/largeCodeGen.out
> 15a16,18
> > java.sql.SQLException: Statement too complex. Try rewriting the query to remove

> complexity. Eliminating many duplicate expressions or breaking up the query and 
> storing interim results in a temporary table can often help resolve this error
> . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:e1 code_leng
> th (65577 > 65535) in generated class org.apache.derby.exe.ac46a08075x010bx203ax 
> d010x000050a9065e9.
> > Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try
>  rewriting the query to remove complexity. Eliminating many duplicate expression
> s or breaking up the query and storing interim results in a temporary table can 
> often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s)
> exceeded: method:e1 code_length (65577 > 65535) in generated class 
> org.apache.derby.exe.ac46a08075x010bx203axd010x000050a9065e9 .
> >       ... 4 more
> 19 del
> < PASS: IN clause with 97000 parameters
> 20 del
> < PASS: PREPARE: IN clause with 98000 parameters
> 21 del
> < PASS: IN clause with 98000 parameters
> 22 del
> < FAILED QUERY: IN clause with 99000 parameters. 
> 22a22,29
> > FAILED QUERY: IN clause with 97000 parameters.
> > java.sql.SQLException: The parameter position '31,465' is out of range.  The 
> number of parameters for this prepared  statement is '31,464'.
> >       at org.apache.derby.client.am.PreparedStatement.setInt(PreparedStatement
> .java(Compiled Code))
> > Caused by: org.apache.derby.client.am.SqlException: The parameter position '31
> ,465' is out of range.  The number of parameters for this prepared  statement is 
>  '31,464'.
> >       at org.apache.derby.client.am.PreparedStatement.checkForValidParameterIn
> dex(PreparedStatement.java(Compiled Code))
> >       at org.apache.derby.client.am.PreparedStatement.checkSetterPreconditions 
> (PreparedStatement.java(Inlined Compiled Code))
> >       at org.apache.derby.client.am.PreparedStatement.setIntX(PreparedStatemen
> t.java(Inlined Compiled Code))
> >       ... 5 more
> 27a35,37
> > java.sql.SQLException : Statement too complex. Try rewriting the query to remove

> complexity. Eliminating many duplicate expressions or breaking up the query and 
> storing interim results in a temporary table can often help resolve this error 
> . SQLSTATE: XBCM4: Java class file format limit(s) exceeded: method:fillResultSe
> t code_length (69127 > 65535) in generated class 
> org.apache.derby.exe.ac46a08075x010bx203axd010x000050a9065e11.
> > Caused by: org.apache.derby.client.am.SqlException: Statement too complex. Try
>  rewriting the query to remove complexity. Eliminating many duplicate expression
> s or breaking up the query and storing interim results in a temporary table can 
> often help resolve this error. SQLSTATE: XBCM4: Java class file format limit(s)
> exceeded: method:fillResultSet code_length (69127 > 65535) in generated class 
> org.apache.derby.exe.ac46a08075x010bx203axd010x000050a9065e11 .
> >       ... 3 more
> 28 add
> > java.sql.SQLException: Java exception: ': java.lang.OutOfMemoryError'.
> > Caused by: org.apache.derby.client.am.SqlException: Java exception: ': 
> java.lang.OutOfMemoryError '.
> >       ... 3 more
> Test Failed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message