I have a DB view which basically consists of two SELECT
queries with UNION ALL
, like this:
CREATE VIEW v AS
SELECT time, etc. FROM t1 /
Encountered same scenario on 11g:
Scenario 1:
CREATE VIEW v AS
SELECT time, etc. FROM t1 // #1...
The following query runs fast, plan looks okay:
SELECT ... FROM v WHERE time >= ... AND time < ...
Scenario 2:
CREATE VIEW v AS
SELECT time, etc. FROM t2 // #2...
The following query runs fast, plan looks okay:
SELECT ... FROM v WHERE time >= ... AND time < ...
Scenario 3, with UNION ALL:
CREATE VIEW v AS
SELECT time, etc. FROM t1 // #1...
UNION ALL
SELECT time, etc. FROM t2 // #2...
The following runs slow. Plan breaks apart t1 and t2 (which were also views) and assembles them as a big series of unions. The time filters are being applied properly on the individual components, but it is still very slow:
SELECT ... FROM v WHERE time >= ... AND time < ...
I would have been happy to just get a time in the ballpark of t1 plus t2, but it was more than double. Adding the parallel
hint did the trick for me in this case. It re-arranged everything into a better plan:
SELECT /*+ parallel */ ... FROM v WHERE time >= ... AND time < ...