PostgreSQL手続き言語のオーバーヘッド（plpython / plsql / pllua ...）
私はPostgreSQL 手続き型言語でのユーザー定義関数 リアルタイムタスクのパフォーマンスに関する情報を見つけようとしています。
- それらは組み込み関数とどのように比較されますか？
- Postgresがplpython vs plpgsql vs pllua関数をどのように呼び出し/管理するのか（オーバーヘッドで）違いはありますか（VM自体）ではなく、Postgres統合/コンテキスト/データ転送側に興味があります）？
- コンテキストは大きなオーバーヘッドですか？リアルタイムデータマッピングに使用できますか（1000クエリ/秒としましょう））
- ユーザー定義関数をplpgsqlで作成して、他のpg/languageを作成する利点はありますか？ documentation については利点が列挙されていますが、すべてのpostgresql手続き型言語に当てはまると思います。
関連する調査結果：
インタプリタ言語のUDFは、Cまたは組み込み関数で記述されたUDFよりも常に低速であり、他のすべては同じです。
各言語バインディングには、PostgreSQLを言語に接続するためのさまざまなコードがあり、最適化の度合いが異なり、一部のデータ型を渡すさまざまな方法などがあります。そのため、確かにバリエーションがあります。ある言語と別の言語で処理が大きく異なるデータ型を渡さない限り、それは巨大であってはなりません。 1つは
hstoreを文字列として渡し、もう1つはdictに変換します。「コンテキスト」が何であるか不明。それを「リアルタイムデータマッピング」に使用できますか。まあ、関数が何をするか、実行しているサーバーで十分に高速かどうか、機能しているクライアントや要件によって異なります。文字列の長さはどれくらいですか？基準。
PL/PgSQLは記述が簡単で、SQLへのより高速なアクセスを提供します。多くのSQLの周りに小さなロジックをラップする必要がある場合は、通常はより良い方法です。数学演算や複雑なアルゴリズムでは非常に遅いため、PLまたはPgSQLの純粋な計算コードは、Cまたはより高速な手続き型言語を優先して、可能な限り回避する必要があります。
CでPL/PgSQLコードを再実装するときのスピードアップは、無視できるものから1000を超えるものまでさまざまです。それはすべて、コードが実際に何をしているかに依存します。
（この種の複数の質問は、明確な回答を得ることが難しいため、Stack Exchangeにはあまり適していません）
コンテキストは大きなオーバーヘッドですか？リアルタイムデータマッピングに使用できますか（1000クエリ/秒としましょう））
パフォーマンスは、ハードウェアと関数の複雑さに依存します。小さな12コアサーバーとFusionIOカード（合計コストは10000ユーロ）で動作するアプライアンスを作成し、20人の同時ユーザーで1秒あたり約2500のトランザクションを実行しました。各トランザクションは、29のストアドプロシージャを呼び出して、データを処理し、有用な情報をクライアントに返します。一部の関数は1つのクエリのみを実行し、他の関数はいくつかのクエリを実行します。合計で、1秒あたり約200000のINSERT、SELECT、およびUPDATEステートメントを実行します。
これはすべてPL/SQL、PL/pgSQL、PL/PerlUで記述されています。また、Cで（一部の）関数を書き換えると、システムがさらに高速に実行できると確信しています。
このアプライアンスでは、ほとんどのパフォーマンスはSSDカードから得られます。単一の回転ディスクでは、このパフォーマンスは得られません。安価なSSDドライブも故障し、1時間（レイドカードのキャッシュのため）動作し、その後ゲームオーバーになります。 FusionIOカードは高価ですが、IOバインドされている場合は非常に良い投資です。
これはわかりにくいです。それは本当にあなたが何をしているかに依存します。例：PL/pgSQLは、大きなSQLステートメントが含まれている場合に最適です。あらゆる種類の分岐、部分文字列管理などがあると、本当におかしくなります。
あなたは本当にケース・ツー・ケースでテストしなければなりませんでした。