Alex Baden

Support for multi-fragment joins has always been poor. There is multi-fragment join hash table construction, but the references from the hash table to the actual data are 0-indexed and therefore...

A few thoughts... On GPU execution, we already support multi-fragment kernels. Therefore, we could have arbitrary sized fragments (yes there is some outer loop overhead but that seems negligible, and...

> > In relation to the idea: if it has to be sent to GPU anyways and we know the total size of what we are sending, we can assemble...

> Yes, this is the goal. An additional challenge here is to use zero-copy fetch as much as possible, i. e. follow arrow chunks for imported tables, or ResultSets when...

I don't know why `launchGpuCode` would be slower with more fragments than with fewer on the same data. The join column iterator is all pre-processing, so that should not effect...

I can confirm updating to openjdk 17 fixes this issue. So, we need to modify conda-forge to pin openjdk >= 17 instead of 11. I will open the conda-forge PR...

https://github.com/conda-forge/hdk-feedstock/pull/54 @Garra1980 @leshikus please take a look.

I switched to manually restoring/saving the cache instead of letting the action handle it. So far it seems to be working. I did notice the save cache prints this warning...

With https://github.com/intel-ai/hdk/pull/416 I have included a change to manually restore and save the cache prior to installing pyhdk libraries, only for the PyHDK pytest job. I have run several times...

Is there a specific failure that has been hard to reproduce? Other than the conda-forge build problems or differences in packages across the CI environments we currently test in, I...