Performance: Mathematical functions

Question

I'm a recent convert to Oracle and need some advice.
Scenario:
1. Our client has a web application written in Java that queries an Oracle database to extract a list of stores based on their location.
2. The client approached us to rewrite the application in .Net, but the database remains Oracle10g
3. In the existing Java application there were no stored procedures used so we created much of the logic, that used to be in Java, in stored procedures.
Problem:
When extracting a list of stores, 5 at the most, the performance is considerably slower than their existing application. One of the points mentioned is that Oracle isn't the best place to put code that relies on mathematical equations.
Finer detail:
Each store record in the database has a latitude and longitude value. The user searches by postal code and the application has to return the X closest stores to them.
We have a function which accepts the lat and long values and calculates a distance based on math equations including the use of Sin, Atan, etc.
So in the select query we would have something to the effect of:
SELECT storeName, round(CalcDistance(parms),13) AS Distance FROM Stores WHERE .... ORDER BY Distance
Should this kind of code be done rather in the business logic layer or are we missing something about Oracle?
Regards,
J.Hov

Answer 1

user11303583 wrote:
One of the points mentioned is that Oracle isn't the best place to put code that relies on mathematical equations. As a general statement that is completely false.
Finer detail:
Each store record in the database has a latitude and longitude value. The user searches by postal code and the application has to return the X closest stores to them.
We have a function which accepts the lat and long values and calculates a distance based on math equations including the use of Sin, Atan, etc.
So in the select query we would have something to the effect of:
SELECT storeName, round(CalcDistance(parms),13) AS Distance FROM Stores WHERE .... ORDER BY DistanceOk, the problem you are experiencing is generally referred to as context switching. This happens when you call a PL/SQL function from within SQL and you're doing it many times e.g. a function call for each row. This is because for each row the function is called and the value is passed back, causing oracle to have to switch between the SQL 'engine' and the PL/SQL 'engine', passing all relevant information in the process.
Likewise you can get a performance problem if you call SQL lots of times from within PL/SQL (rather than using single SQL's effecting many rows).. e.g.
SQL> ed
Wrote file afiedt.buf
  1  declare
  2    v_sysdate DATE;
  3  begin
  4    v_sysdate := SYSDATE;
  5    INSERT INTO mytable SELECT rownum FROM DUAL CONNECT BY ROWNUM <= 1000000;
  6    DBMS_OUTPUT.PUT_LINE('Single Transaction: Time Taken: '||ROUND(((SYSDATE-v_sysdate)*(24*60*60)),0));
  7    EXECUTE IMMEDIATE 'TRUNCATE TABLE mytable';
  8    v_sysdate := SYSDATE;
  9    FOR i IN 1..1000000
10    LOOP
11      INSERT INTO mytable (x) VALUES (i);
12    END LOOP;
13    DBMS_OUTPUT.PUT_LINE('Multi Transaction: Time Taken: '||ROUND(((SYSDATE-v_sysdate)*(24*60*60)),0));
14    EXECUTE IMMEDIATE 'TRUNCATE TABLE mytable';
15* end;
SQL> /
Single Transaction: Time Taken: 1
Multi Transaction: Time Taken: 37
PL/SQL procedure successfully completed.
SQL>As you can see the performance difference can be quite a good factor higher if there's a lot of context switching.
The way to solve this is to either write your SQL statement within PL/SQL so that it processes many rows in one go, or for your particular issue, re-write your SQL statement to do the calculation as part of the SQL rather than calling user defined PL/SQL functions. You may find using Oracle's built in spatial packages useful as these are already compiled as low-level code and optimised for performance, but you may find, if the calculations can be done within the SQL itself it will be the quickest.