I had an interesting observation and thought to revisit this thread as it's relevant to the topic.
I am facilitating some testing of other applications feeding from HANA. In many of the previous testing using views to "extract" data from HANA, very wide reads on views have caused extremely high memory usage, and only one single thread can be observed running for a long time.
However, when a very wide select (think SELECT *) is executed directly against the column table, it looks like there is another process going on. There appear to MANY small reads/threads popping up for just a few seconds and then falling off. When I look at the details in performance/threads, I can see the fetched record count is constantly increasing, and the visualize plan looks like this.
Since no specific engine is called out here on the components (JE/BW/CE) and based on the thread activity mentioned above, I have to assume there are just many small reads occurring in the SQL engine itself.
What is interesting to me is this buffer concept. I previously observed that in the other engines, the entire result is built before really pushing out for consumption, whereas here it looks like small pieces are being constantly added to this "buffer". It's really slow, but really cheap when I am monitoring the performance.
The thread details
At some later point
Lars, any info you can provide about what's going on "under the covers" on this? Is there some arbitrary cursor size that just keeps adding to some buffer/providing results to the consumer and then keeps moving on, unlike the OLAP/Calc engines that attempts to build the entire set?
The expectation was that large reads/extracts out of HANA would be very expensive to materialize the results, but this seems to contradict that assumption - it's just much slower.
Regards,
Justin