Interpreting Predicate and Filter information from the explain plan

Question

Can somebody help in understanding how does the predicate and filter operation effects the execution plan.or how can I conclude the predicate or filter operation chosen by optimizer is not optimized.

Answer 1

User445775,
The paraphrase that I provided in my previous post was from page 74 of "Cost-Based Oracle Fundamentals".
How to word the explanation...
Assume that you have a database table which contains all of the phone numbers and addresses for people in a state. A query is executed to find user445775 in the city named "Redmond". Assume that the query looks like this:
SELECT
  PHONE
FROM
  PHONE_NUMBERS
WHERE
  CITY = 'Redmond'
  AND FULL_NAME = 'user445775';Assume that there are no indexes on the table. The DBMS_XPLAN would show two filter predicates applied during a full tablescan - this probably indicates an inefficient access path, especially if there are a very small percentage of people matching the WHERE clause restrictions on the table.
Now, assume that an index is created on the CITY column. The DBMS_XPLAN would show an access predicate applied to the index on the CITY column, and a filter predicate on the table access by index for the FULL_NAME. We eliminated a large number of possible rows by applying the access predicate to jump directly to the rows with the city of interest, and then filtered out those names which were not 'user445775'. This is not terribly efficient, especially if there are a large number of people in 'Redmond' that need to be filtered out.
Now, assume that we drop the index on the CITY column and create an index on the FULL_NAME column. The DBMS_XPLAN would show an access predicate applied to the index on the FULL_NAME column, and a filter predicate on the table access by index for the CITY column. This could be a fairly efficient plan if there are only a couple rows in the table with FULL_NAME of 'user445775', as few rows will be discarded after the index access to find those with CITY = 'Redmond'.
Now, assume that we drop the index on the FULL_NAME column and create a composite index on CITY,FULL_NAME. The DBMS_XPLAN would show an access predicate applied to the index on the CITY and FULL_NAME columns and there would not be a filter predicate on the table access by index - in this case, we will not discard any rows once retrieved by the index access.
Page 211 of "Troubleshooting Oracle Performance" also shows a clear explanation of access and filter predicates.
Think of access predicates (on indexes at least) as throwing out rows before they are retrieved from disk (or memory), and filter predicates as throwing out rows after they are retrieved from disk (or memory).
Charles Hooper
IT Manager/Oracle DBA
K&M Machine-Fabricating, Inc.