devxlogo

Predicate Pushing

Predicate Pushing

Oracle supports the pushing of predicates into a given view. Suppose you have a set of layered views:

--View OneCREATE VIEW vw_layer_oneAS SELECT * FROM emp;-- View TwoCREATE VIEW vw_layer_two_dept_100AS SELECT * FROM vw_layer_oneWHERE deptno=100;

Then assume you issued this query:

SELECT * FROM vw_layer_two_dept_100WHERE empid=100;

The predicate in this statement is WHERE empid=100;. You may have one of tens or even hundreds of predicates (if you have hundreds, you don’t want to be supporting your SQL code!). In many cases, Oracle will push those predicates down into the views being called. Thus, Oracle will transform the vw_layer_one view into a SQL statement that looks like this:

CREATE VIEW vw_layer_oneAS SELECT * FROM empWHERE deptno=100AND empid=100;

Note that both the predicate from vw_layer_two (where deptno=100) and the predicate from the SQL statement being executed (where empid=100) are pushed down into the final view that is executed. This can have significant performance benefits, because now the bottom view can possibly use an index if one exists on deptno and/or empid.

Predicate pushing has a number of restrictions that are beyond the scope of this tip, but you can find them in the Oracle documentation. Also, any predicate pushing may result in a hard parse of the underlying SQL that is executed. Hence, it is important to make sure you use bind variables instead of literals in SQL code calling views. Your SQL should look something like this, for best performance:

SELECT * FROM vw_layer_two_dept_100WHERE empid=:b100;
devxblackblue

About Our Editorial Process

At DevX, we’re dedicated to tech entrepreneurship. Our team closely follows industry shifts, new products, AI breakthroughs, technology trends, and funding announcements. Articles undergo thorough editing to ensure accuracy and clarity, reflecting DevX’s style and supporting entrepreneurs in the tech sphere.

See our full editorial policy.

About Our Journalist