The short answers are:
(1) you can change any of the values on the list
(2) it's not documented anywhere (except in an advanced training class I wrote years ago but was canned by Informix USA under the "not invented here" rule)
The first two options are about forcing the Aggregator stage to update its status so that row counts can be monitored. Without these, the Aggregator (with unsorted input particularly) would just sit there gobbling up rows until they were all in, then blast the result rows out in a flatulent burst.
The remaining four are about memory management for the Aggregator stage. The TableSize (8192 bytes) figure is the initial amount of memory allocated by the Aggregator stage. This memory stores a set of rows corresponding to the output row definition; each grouping value and each aggregating value is represented.
As more and more rows arrive with different grouping values, more memory is required. If the input is sorted, a change in value of one of the sorted columns can trigger output of some rows, with that memory able to be freed.
Otherwise, there comes a point when the initial allocation of memory has all been consumed. At this point, the allocation is increased by multiplying its current size by the ResizeAt figure. So, by default, when the initial 8KB has been used, another 8KB is allocated; when that 16KB has been used another 16KB has been allocated.
And so on, until the size specified in the Resize2Threshold has been reached. When this 512KB has been used, the other multiplier (the ResizeBy figure is used), so the allocation is increased to 4MB.
The options are not really well named in my opinion.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
