Oracle 10g: Does query with no where caluse always do table scan
-
Being a SQL Server developer, I am not familiar with Oracle. We have a third party product using Oracle 10g that uses a dropdown to show the unique values from a field in a table of 2.5 million rows, but with only 50 unique values. There is no index on the field and it takes a minute to run the query 'select distinct field from table order by 1' used to populate the dropdown. Adding an index on that field should allow the optimiser to scan the index rather than the table, and as the indexed field is 1/50th of the table’s row length I would expect to see a similar decrease in the time taken to run the query. However, it made no difference to the performance. I have been told that Oracle will ALWAYS do a table scan if there is no where clause in the query. If this is the case without access to the source to change the query, I seem to have no way to optimise this. Is what I heve been told true? If not how can I get the optimiser to use the index without being able to chnage the SQL in the query?
-
Being a SQL Server developer, I am not familiar with Oracle. We have a third party product using Oracle 10g that uses a dropdown to show the unique values from a field in a table of 2.5 million rows, but with only 50 unique values. There is no index on the field and it takes a minute to run the query 'select distinct field from table order by 1' used to populate the dropdown. Adding an index on that field should allow the optimiser to scan the index rather than the table, and as the indexed field is 1/50th of the table’s row length I would expect to see a similar decrease in the time taken to run the query. However, it made no difference to the performance. I have been told that Oracle will ALWAYS do a table scan if there is no where clause in the query. If this is the case without access to the source to change the query, I seem to have no way to optimise this. Is what I heve been told true? If not how can I get the optimiser to use the index without being able to chnage the SQL in the query?
From my experience, I would say, yes, Oracle will do a table scan if there is no where clause. However, adding and index to the table may not solve the problem either, the entire table may be 2.5 million rows yet there are only 50 unique values, this means that each unique values a has about 50,000 index entries. Oracle would have to read 50,000 index records to satisfy the query. The optimizer may choose to perform a table scan rather then read the index. Let me contact a friend of mine who is a true Oracle expert and see if there is anything that can be done. (He worked for Oracle for 18 years, now is a consultant specializing in Performance Tuning) I'm afraid you may have to live with a poorly designed application.
-
Being a SQL Server developer, I am not familiar with Oracle. We have a third party product using Oracle 10g that uses a dropdown to show the unique values from a field in a table of 2.5 million rows, but with only 50 unique values. There is no index on the field and it takes a minute to run the query 'select distinct field from table order by 1' used to populate the dropdown. Adding an index on that field should allow the optimiser to scan the index rather than the table, and as the indexed field is 1/50th of the table’s row length I would expect to see a similar decrease in the time taken to run the query. However, it made no difference to the performance. I have been told that Oracle will ALWAYS do a table scan if there is no where clause in the query. If this is the case without access to the source to change the query, I seem to have no way to optimise this. Is what I heve been told true? If not how can I get the optimiser to use the index without being able to chnage the SQL in the query?
The only way you will know if there is a table scan or not is to look into the plan generated for the SQL. If a where clause is an absolute necessity, which I doubt, then you can always add something like
where 1 = 1. But without access to modify the source for the SQL you are in trouble. Also are the indexes in separate tablespaces and files from the data? If not that may be why you don't see any difference. :)Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
-
The only way you will know if there is a table scan or not is to look into the plan generated for the SQL. If a where clause is an absolute necessity, which I doubt, then you can always add something like
where 1 = 1. But without access to modify the source for the SQL you are in trouble. Also are the indexes in separate tablespaces and files from the data? If not that may be why you don't see any difference. :)Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
-
Explain Query in PLSQL Developer shows: SELECT STATEMENT.GOAL=ALL_ROWS SORT UNIQUE TABLE ACCESS FULL The TABLE ACCESS FULL has cardinality of 2.5 milion, the other two 50, so I guess that is a full table scan
In PLSQL Developer, try adding theses different where clauses and see if a TABLE ACCESS FULL still shows up.
where 1 = 1
or
where nvl(field,field) = field
The last one has the the field you are selecting in the where clause and may force the use of the index. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
-
The only way you will know if there is a table scan or not is to look into the plan generated for the SQL. If a where clause is an absolute necessity, which I doubt, then you can always add something like
where 1 = 1. But without access to modify the source for the SQL you are in trouble. Also are the indexes in separate tablespaces and files from the data? If not that may be why you don't see any difference. :)Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
-
In PLSQL Developer, try adding theses different where clauses and see if a TABLE ACCESS FULL still shows up.
where 1 = 1
or
where nvl(field,field) = field
The last one has the the field you are selecting in the where clause and may force the use of the index. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
-
Explain Plan with - where field <> 'imposibleValue'
SELECT STATEMENT.GOAL=FIRST_ROWS
SORT UNIQUE NOSORT
INDEX FULL SCANand the cost has reduced from 22,089 to 344 However, it only helps my understanding, not the problem!
It's always good to be able to understand a problem. At least now you have really good evidence to provide to the 3rd party vendor with a request for a change. Whether it is accepted or not is unfortunately an entirely different situation. Good luck with it though. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]
-
You are right - adding a 'null' where clause such as where field <> 'imposibleValue' reduces the execution time from 1 minute to 1 second, so that is obviously forcing the use of an index. Shame I can't change the sql :(
Wow! This thread just tought me that I had really good luck when I designed the generation of the sql queries in our application: I do often start the WHERE clause with a "WHERE (1=1) " so that I can add further conditions simply with " AND " (instead of checking if the WHERE clause is still empty or not) - I did so because of that laziness...
-
Wow! This thread just tought me that I had really good luck when I designed the generation of the sql queries in our application: I do often start the WHERE clause with a "WHERE (1=1) " so that I can add further conditions simply with " AND " (instead of checking if the WHERE clause is still empty or not) - I did so because of that laziness...
See, it pays off to be lazy sometimes. :)
Chris Meech I am Canadian. [heard in a local bar] In theory there is no difference between theory and practice. In practice there is. [Yogi Berra]