We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
基本、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
The text was updated successfully, but these errors were encountered:
トランザクションログからの復旧ができないので、このモードを使用する場合は、SELECT INTOした先のテーブルは UNLOGGED テーブルでなければならない。
SELECT INTO
UNLOGGED
ただ、別のソーステーブルから作り出すテーブルであれば、クラッシュ時のリカバリ不能に関してはそれほど大きな問題かどうかは微妙なところかも…。
Sorry, something went wrong.
No branches or pull requests
基本、PG-Stromは大量のデータから少数のレコードを検索する、あるいはGROUP BYで集約するワークロードが中心。
大量の行を入力して、大量の行を出力するのは苦手。
⇒なぜなら、書き込み側でCPU・I/Oボトルネックが発生するため。
では、GpuScan / GpuJoin の結果を、そのままGDSの書き込みモードでストレージに書き出せばどうか。
空テーブルへの追記ONLYのパターンであれば、並行トランザクションの問題は発生しなさそう。
⇒それを行うのは SELECT INTO のパターン(完全排他ロック下で空テーブルへの書き込みを行う)
検討課題
これの
Gather
のあとを乗っ取るには?⇒要調査The text was updated successfully, but these errors were encountered: