Fool hardedly I tried to "filter" the records at the relationship level with different TO's (as you would with filtering portals at the relationship level) so that it wouldn't have to evaluate the full record set, but I'm not using portals for this data since it's a report and it doesn't work without portals.
Defining a relationship doesn't mean you need a portal to put it to use … and basically, only a single relationship is required …
In the Orders table, define a calculation field, type text, as Year ( EntDate ) & "|" & Month ( EntDate ), and use it as match for a selfjoin relationship. Then create a calculation field Sum ( Orders_selfJoin::ExtPOCost ) and put it in the Grand Total part.
Actually, you don't even need that calculation field; simply use a summary field for ExtPOCost, say, sExtPOCost. The sExtPOCost field from the TO which your report is based on will show the daily summary; put the same field via the selfjoin relationship on the layout (i.e. Orders_selfJoin::sExtPOCost), and you'll see the monthly sum.
If you want to use SQL, then, instead of creating an unstored calculation field and target that (which is probably causing the increasing sluggishness, at least in part), directly query the date field (which is stored), like
Let ( [
cd = Get ( CurrentDate ) ;
m = Month ( cd ) ;
y = Year ( cd )
ExecuteSQL ( "
SELECT Sum ( ExtPOCost )
WHERE EntDate BETWEEN ? AND ?
" ; "" ; "" ; Date ( m ; 1 ; y ) ; Date ( m + 1 ; 0 ; y )