Skip to Main Content

SQL & PL/SQL

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

How to optimize performance of this SQL query

Gayathri VenugopalJul 6 2015 — edited Jul 6 2015

Hi,

I need to find the age for each day ,but I need it for all previous dates in one query. So I used the following query:

select trunc(sysdate) - level + 1 DATE

,trunc(sysdate) - level + 1 - created_date AGE 

  from items

connect by trunc(sysdate) - level + 1 - created_date > 0

I am getting output(FOR DATE & AGE) which is fine and correct:

DATE              AGE

   --------- ----------

   6-JUL-15          22

   5-JUL-15          21

   4-JUL-15          20

   3-JUL-15          19

   2-JUL-15          18

   1-JUL-15          17

   30-JUN-15         16

   29-JUN-15         15

   28-JUN-15         14

   27-JUN-15         13

   26-JUN-15         12

   25-JUN-15         11

   24-JUN-15         10   

Now I need to calculate average age for each day so I added average in the following query:

select trunc(sysdate) - level + 1 DATE ,

   avg(trunc(sysdate) - level + 1 - created_date ) AVERAGE_AGE  

   from items

   connect by trunc(sysdate) - level + 1 - created_date > 0

   group by trunc(sysdate) - level + 1


is this query correct? When I add aggregate function (avg) to this query, it takes 1 hour to retrieve data .When I remove the average function from query it gives result in 2 seconds?What is the possible solution to calculate average without affecting the performance ?Please help

This post has been answered by BluShadow on Jul 6 2015
Jump to Answer

Comments

843793
Well, this was a shot in the dark, but I tested it and it seems to be the problem: remove the parens around i.next()!

After doing so, running the code in your post instead provides a "NoSuchElementException" from the iterator (completely expected). I'm not sure if this a bug in the compiler, or if it has something to do with the way the code gets expanded. Maybe if someone thinks about it long enough they'll be able to come up with a reason.
843793
Why would you expect to use those parens like that anyway?
843793
Why would you expect to use those parens like that
anyway?
I can see that the parens are redundant - and as the other responder pointed out, the error goes away when they are removed...however, I'm still curious...

Firstly, is it actually an error to use the parentheses in that way?

Secondly, although the offending line is executed in the example I gave, the code that I pulled the example from is a bit stranger - when I try to instantiate a class (call it B), that contains a method with the redundant parentheses, I get the same error - even though the offending line isn't executed (I can post the code tonight if anyone is interested).

Gareth
843793
Here's the code:

import java.util.*;
class A {
public static void main (String argv[]) {
B bb = new B();
}
}

class B {

void methodC() {
ArrayList<Boolean> B = new ArrayList<Boolean>(10);
Iterator<Boolean> i = B.iterator();
boolean b = (i.next()).booleanValue();
}
}

843793
This is definitely a bug in the compiler. The bytecode generated for B.methodC() is:

Codeview "bytecode" for void B.methodC():
#3/Test.java:12 - new class java.util.ArrayList
#4/Test.java:12 - dup
#5/Test.java:12 - bipush (byte)10
#6/Test.java:12 - invokespecial public java.util.ArrayList(int)
#7/Test.java:12 - astore_1 lv_1
#8/Test.java:13 - aload_1 lv_1
#9/Test.java:13 - invokevirtual public java.util.Iterator java.util.AbstractList.iterator()
#10/Test.java:13 - astore_2 lv_2
#11/Test.java:14 - aload_2 lv_2
#12/Test.java:14 - invokeinterface public abstract java.lang.Object java.util.Iterator.next()
#13/Test.java:14 - invokevirtual public final boolean java.lang.Boolean.booleanValue()
#14/Test.java:14 - istore_3 lv_3
#15/Test.java:15 - return

and it's clear that between instruction #12 and instruction #14 a typecast is missing.

I'll add this to my list of known prototype compiler bugs at
http://cag.lcs.mit.edu/~cananian/Projects/GJ/
1 - 5
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Aug 3 2015
Added on Jul 6 2015
3 comments
265 views