Well, it is true that the information for the ALL rows is present 
in the base query. But then adding the ALL rows directly after examining 
the result, we think, is not as efficient as it sounds.

        Consider the situation you are talking about. Suppose we decide to 
add the ALL rows directly to the base result. A major drawback would be 
that we would have to execute the whole WHERE clause and/or joins over the 
original relations, which, in case of large databases, would cause a lot of 
overhead. Whereas, executing the UNION of SELECT queries on the base table 
obtained from the base query (WITHOUT CUBE) does not have to handle these 
situations (WHERE clause, JOIN cases). More importantly, this is faster 
(due to the relatively smaller size).

        It is true that a summary table is much smaller than the base 
table. But a DATACUBE (as per definition) takes into account even the base 
query (the one WITHOUT CUBE). We have referred some sites and articles 
before planning the code. Since we are building a DATACUBE all the 
information is required.

        Hope we have made ourselves clear.


On Mon, 30 Jun 2003, Andrew Dunstan wrote:

> I'm curious to know why you implement this as a union of queries, since,
> unless my understanding is badly awry, you have all the information
> necessary for the ALL rows by running the base (ie. without cube) query, Why
> not just run that query and then add the ALL rows from examining the
> results? ISTM that would be more efficient, since the summary table is in
> most real world situations likely to be far, far smaller than the base
> table.
> andrew

---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?


Reply via email to