This would likely give us a good performance boost in these operations too I believe.

Have to put on hold for a day or two. hopefully can still finish this by Friday.

Finally finished this one. Changed the way memory was saved.

I implemented the original idea and once it was working, I saw that mem usage hadn't dropped as much as i thought it should have.

Investigated, found that the bulk of the memory used in my tests was used by the hash table itself rather than the nodes of the table. I added a hint to allow our allocators to distinguish between the two types of allocations. Nodes are allocated by the pool, tables allocated by the system allocator, so that they could be deallocated when they need to grow. This alone cut memory usage by ~70%. (4GB down to 1.2GB). This also has the benefit of being automatically applicable to every hash table using our STLPoolAllocator (all join types, agg/group-by, distinct, union) on the UM and PM.

The original idea above saved little memory by comparison, 200MB, was relatively complex, and was only implemented for numeric UM joins, so I will keep that aside in a separate branch in case we really need to save a little more mem.

My mistake, faulty KPIs. Now seeing the expected 25% mem reduction. Also GTK, the std hash & set structs use 8 bytes more per node than the tr1 versions.

The extra work required by the new functors results in a performance drop is 15-20% end-to-end according to my benchmarks, so concluded that this isn't worth doing. I will keep the work in the um-join-mem-reduction branch in my fork of the engine repo.