ODCIAggregateMerge without parallel_enabled : <p>These are quotes from <a href="https://docs.oracle.com/cd/B28359_01/appdev.111/b28425/aggr_functions.htm" rel="noreferrer">Oracle docs</a>:</p>

<blockquote>
  <p>[Optional] Merge by combining the two aggregation contexts and return a single context. This operation combines the results of aggregation over subsets in order to obtain the aggregate over the entire set. This extra step can be required during <strong>either serial or parallel</strong> evaluation of an aggregate. If needed, it is performed before step 4:  </p>
</blockquote>

<p>,</p>

<blockquote>
  <p>The ODCIAggregateMerge() interface is invoked to compute super aggregate values in such rollup operations.</p>
</blockquote>

<p>We have an aggregate function, that we do NOT want to ever run in parallel.<br>
The reason is that the merging of contexts would be resource consuming and would force us to use different data structures than we are using now, effectively offseting any performance benefits from parallel execution.</p>

<p>Thus, we did <strong>not</strong> declare our function as <em>parallel_enabled</em>, and instead return ODCIconst.Error in ODCIAggregateMerge 'just in case'.</p>

<p>However, the first quote docs claim, that merge may occur even in serial evaluation.<br>
Super-aggregates (rollup, cube) are obvious examples, but are there any others?</p>

<p>I've been totally unable to reproduce it with simple group by, merge is never called without parallel_enabled and it seems that always only one context is created within the group.  </p>

<p>Is it safe to assume that without the parallel_enabled set, merge will never be run?<br>
Have you ever seen a counterexample to that rule?</p>
