Open kaigai opened 1 week ago
基本、PG-Stromは大量のデータから少数のレコードを検索する、あるいはGROUP BYで集約するワークロードが中心。 大量の行を入力して、大量の行を出力するのは苦手。 ⇒なぜなら、書き込み側でCPU・I/Oボトルネックが発生するため。
では、GpuScan / GpuJoin の結果を、そのままGDSの書き込みモードでストレージに書き出せばどうか。 空テーブルへの追記ONLYのパターンであれば、並行トランザクションの問題は発生しなさそう。 ⇒それを行うのは SELECT INTO のパターン(完全排他ロック下で空テーブルへの書き込みを行う)
検討課題
postgres=# explain select * into hogehoge from testdata where memo like '%abc%'; QUERY PLAN -------------------------------------------------------------------------------------------- Gather (cost=1100.00..3901.16 rows=39 width=106) Workers Planned: 2 -> Parallel Custom Scan (GpuScan) on testdata (cost=100.00..2897.26 rows=16 width=106) GPU Projection: id, memo GPU Scan Quals: (memo ~~ '%abc%'::text) [rows: 400001 -> 16] GPU-Direct SQL: enabled (N=2,GPU0,1) (6 rows)
これの Gather のあとを乗っ取るには?⇒要調査
Gather
トランザクションログからの復旧ができないので、このモードを使用する場合は、SELECT INTOした先のテーブルは UNLOGGED テーブルでなければならない。
SELECT INTO
UNLOGGED
ただ、別のソーステーブルから作り出すテーブルであれば、クラッシュ時のリカバリ不能に関してはそれほど大きな問題かどうかは微妙なところかも…。
基本、PG-Stromは大量のデータから少数のレコードを検索する、あるいはGROUP BYで集約するワークロードが中心。 大量の行を入力して、大量の行を出力するのは苦手。 ⇒なぜなら、書き込み側でCPU・I/Oボトルネックが発生するため。
では、GpuScan / GpuJoin の結果を、そのままGDSの書き込みモードでストレージに書き出せばどうか。 空テーブルへの追記ONLYのパターンであれば、並行トランザクションの問題は発生しなさそう。 ⇒それを行うのは SELECT INTO のパターン(完全排他ロック下で空テーブルへの書き込みを行う)
検討課題
これの
Gather
のあとを乗っ取るには?⇒要調査