Hi Aleksander, I currently have the distributed model in mind: temporary-table rows would be stored and partitioned similarly to regular Ignite tables/caches. Query fragments running on different nodes should be able to access their local partitions directly.
As I understand it, the SQL standard defines temporary-data visibility and lifecycle, but does not require a SQL session or its temporary data to survive a node failure. Therefore, for the initial implementation, failure of the session-owning node could terminate the session. Its remaining temporary data would then be cleaned up across the cluster, possibly asynchronously. In other words, regular cache mechanisms can be used for storing and processing the rows, but preserving the temporary data after the loss of the session itself is not a requirement.
