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