[idea] Large-tables GpuJoin

[kaigai]

現状、GpuJoinではOUTER側のテーブルが巨大で、INNER側は比較的小さいという前提を置いている。 これは、GpuHashJoinでINNER側がバッファに載らないと困るから。

一般に、Large-tablesなJOINは遅いと相場が決まっている。 ではINNERを何個かに分割してOUTERのスキャンを何回か繰り返せば済むレベルの大きさならどうか？

アプローチ① INNERを分割して、OUTERのスキャンを何度か繰り返せば行ける。 その時、JOIN結合キーのHASH値を元に何個かのテーブルに分ければ、JOINのOUTER-SCAN時に早い段階でデータを落とせる。

アプローチ② KDS（kern_data_store）の64bitオフセット版を作って、Managed Memoryを使ったメモリオーバーコミットもあり。 この場合、INNERの構築に相当な時間を要する可能性も。 INNER配下にGpuScanが繋がっている場合、GpuProjectionに相当する部分を、Inner-Bufferへの書き込みという形で実装 すれば、一度CPUに戻す必要はないのでは？

[kaigai]

bacbf0599b39ab272c84989ec17b8fee424b2b9f で Inner-Hash-Table のオフセット値が64bitになるように修正。 そもそもが GPU のメモリが4GBとか8GB（かつ、Memory Over Commitなし）とかいう時代の設計であり、 これによるメモリ消費量増加による影響は軽微。コードの複雑さを増してしまうため、基本的に__kds_packedと__kds_unpackによる35bitオフセット値の表現は廃止の方向で。

[kaigai]

なお、これは単純に機械的にオフセット値の表現を64bit化しただけであり、いったん、PostgreSQLバックエンドの ローカルメモリに読み出したタプルを保存 ⇒ 共有メモリ（/dev/shm）を介してGPU-Serviceへ送出するという流れは、 ホストメモリの過剰な消費を招くため、あまり望ましくはない。

GpuJoinの配下にGpuScanが含まれている場合、最終 depth での GPU-Projection をハッシュ表への書込みへ変更する事で、 Host <-> GPUの余計なデータ移動を避ける事ができる・・・はず。

ただしこの場合、一件でもCPU Fallback対象タプルが含まれていてはダメなので、まず、CPU Fallbackの処理方式改良から。

[kaigai]

動作確認できたので close