Details
Major Description
The SpoolingResultIterator#OnDiskResultIterator switches between two pre-allocated buffers as reading buffers for the tuple result, based on the assumption that the outer ResultIterator consumes the returned tuple in a streaming fashion and will never look back/forward outside 2-tuple span.
However, some usages fail this assumption:
1. OrderedResultIterator: It adds all tuples into its MappedByteBufferQueue on initialization, which is maintained by a priority queue before threshold is reached and spooling to files.
This is not revealed in most test cases because, most importantly, OrderedResultIterator is not commonly used on clientside (only ClientProcessingPlan does)
2. Child/parent hash-join optimization, which uses a list of PK values to create an InListExpression.
It might be easy to walk around the second usage here though, but may need more consideration on the first one.
I am thinking to take away SpoolingResultIterator at all if there is an outer ResultIterator being OrderedResultIterator.
