Question

i.e, if current view is generated by joining large tables and it includes a lot of sum operation, like this:

CREATE OR REPLACE VIEW V_WorldReport AS

SELECT cc.id as id, c.propertyA, c.propertyB, 

SUM(DECODE(cc.KEY_ID, 0, cc.NORTH)) AS ONE_NORTH, SUM(DECODE(cc.KEY_ID, 0, cc.EAST)) AS ONE_EAST, 
SUM(DECODE(cc.KEY_ID, 0, cc.SOUTH)) AS ONE_SOUTH, SUM(DECODE(cc.KEY_ID, 0, cc.WEST)) AS ONE_WEST, 

SUM(DECODE(cc.KEY_ID, 1, cc.NORTH)) AS TWO_NORTH, SUM(DECODE(cc.KEY_ID, 1, cc.EAST)) AS TWO_EAST, 
SUM(DECODE(cc.KEY_ID, 1, cc.SOUTH)) AS TWO_SOUTH, SUM(DECODE(cc.KEY_ID, 1, cc.WEST)) AS TWO_WEST, 

SUM(DECODE(cc.KEY_ID, 2, cc.NORTH)) AS THREE_NORTH, SUM(DECODE(cc.KEY_ID, 2, cc.EAST)) AS THREE_EAST, 
SUM(DECODE(cc.KEY_ID, 2, cc.SOUTH)) AS THREE_SOUTH, SUM(DECODE(cc.KEY_ID, 2, cc.WEST)) AS THREE_WEST, 

....

SUM(DECODE(cc.KEY_ID, 6, cc.NORTH)) AS SEVEN_NORTH, SUM(DECODE(cc.KEY_ID, 6, cc.EAST)) AS SEVEN_EAST, 
SUM(DECODE(cc.KEY_ID, 6, cc.SOUTH)) AS SEVEN_SOUTH, SUM(DECODE(cc.KEY_ID, 6, cc.WEST)) AS SEVEN_WEST

FROM c 
join cc on c.fid = cc.id
GROUP BY cc.id, c.propertyA, c.propertyB;

As the table is huge so performance is great concern, and as the original table c and cc are update very often so it seems oracle view or materialized view are equal in the performance(but I am not sure). Here are some questions regarding the design:

  1. In this joining, if a query only contain one SUM operation, is there a lot performance improvement than like 20 SUMs in the same query? If so, shall I separate the query into 20 views, so that one SUM per each view?

  2. Materialized view gives the flexibility to create index, so, if I make this view as materialized view and create index on each sum result column, as the original table updates very often and requires the view should be synchronized with, can the index contributes to better performance?

Thanks

Was it helpful?

Solution

I don't think that separating SUM() (95% certanty) would help.

Physical READS are much more expensive than agregate SUM() function.

With Materialized view you may find a balance of refreshing it and getting out the results.

Maybe you can slice your data into 2 parts, hot and cold. And build MV only for the cold part.

Or maybe it is possible to partition you data, so that DB needs to join only chanks on the same partition.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top