At 10:19 AM 23/09/2004 +0200, you wrote:

> Hi All
>
> I have a report that uses a SP.
>
> select b.name, b.region, b.orderappend, a.gp gpa, a.turnover turnovera,
> a.orders ordersa, a.rank ranka, b.gp gpb, b.turnover turnoverb, b.orders
> ordersb, b.rank rankb from
> P_GROUP_GP_RANKED('01-feb-2004','14-feb-2004') b join
> P_GROUP_GP_RANKED('01-jan-2004','14-jan-2004') a on a.orderappend =
> b.orderappend
>
> The above works fine and returns in seconds on huge volumes of data, but
> some stores from the FEB period did not exist in the JAN period, so they
> don't appear in the data.
> I would have thought the following left outer join would solve the problem
> ...
>
> select b.name, b.region, b.orderappend, a.gp gpa, a.turnover turnovera,
> a.orders ordersa, a.rank ranka, b.gp gpb, b.turnover turnoverb, b.orders
> ordersb, b.rank rankb from
> P_GROUP_GP_RANKED('01-feb-2004','14-feb-2004') b left outer join
> P_GROUP_GP_RANKED('01-jan-2004','14-jan-2004') a on a.orderappend =
> b.orderappend
>
> ... and it does, but only after bogging the server down for up to 15
>minutes
> and to such an extent that it overheated!
>
> Any ideas on why this is happening and how to get around it?
> Water cooling the server is not an option :)

What about water-cooling the programmer? Why on earth would you want to do
this? The mind boggles at the serpentine internals of it. Why not just
write a single stored procedure to get the set?

./h