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
----- Original Message -----
From: "sumit" <sumit@gdit.iiit.net>
To: <pgsql-patches@postgresql.org>
Sent: Monday, June 30, 2003 6:04 AM
Subject: [PATCHES] Patch for adding DATACUBE operator
>
> Hi!
>
> We have added the CUBE operator for PostgreSQL. Please find the
> attached patch.
>
> Another thing to note is that the file datacube.c should
> be placed in src/backend/tcop/ and datacube.h should be in src/include.
>
> The syntax of the query is
>
> SELECT <field list><aggregate list>
> INTO <destination table>
> FROM <table expression>
> WHERE <search condition>
> GROUP BY <aggregate list>
> HAVING <search condition>
> WITH CUBE;
>
> An example along with the output is provided in the
> README.datacube file. Kindly have a look. Let us know your response.
>
> Srikanth M
> Sumit Kumar Mukherjee
>
----------------------------------------------------------------------------
----
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: the planner will ignore your desire to choose an index scan if your
> joining column's datatypes do not match
>