投稿のタイトルがおかしいと感じる人もいます。 確かに、彼らの正しい考えで、サーバーでのリクエストの実行を遅くするのはなぜですか？
「長いクエリでクライアントプログラムのインターフェースがどのように機能するかを確認するには」と答えます。 このような問題は、
ERデザイナーの基本構造のインポートの実装中に発生しました。
私の謙虚な意見では、プログラムのインターフェースは、長い要求の間、3つの側面を提供する必要があります：
- あらゆる種類の統計とアニメーション（？）でユーザーの目を楽しませます。
- ユーザーにクリックさせたり、何か間違ったことをさせたりしないでください。
- 一方、長いプロセスを停止する機会を与えることが不可欠です。
もちろん、クライアントプログラムコードにあらゆる種類の
スリープ（）を挿入することを禁止する人はいませんが、これには何か悪があります。 また、組み込み関数
pg_sleep（）を使用できます。この関数のパラメーターには、リクエストの実行を停止する秒数を渡すことができます。
SELECT pg_sleep(1.5);
データベース内のテーブルのリストを返すクエリにブレーキをかけましょう。
SELECT oid :: regclass FROM pg_class WHERE relkind = 'r'
例1
FROMセクションに
pg_sleep（）呼び出しを
配置できます。
SELECT oid::regclass FROM pg_class, pg_sleep(10) WHERE relkind = 'r'
この場合、関数は1回だけ実行され、合計実行時間は約10秒になります。 さらに、データセット全体がすぐに全体として返されます。
例2
SELECTセクションに
pg_sleep（）呼び出しを
配置できます。
SELECT oid::regclass, pg_sleep(1) FROM pg_class WHERE relkind = 'r'
同じ場合、関数はデータセットの各行に対して1回実行されます。 つまり、データベースにあるテーブルと同じ回数。 このアプローチには、もう1つの利点があります。 非同期の要求処理を使用すると、たとえば
この方法またはその
方法で 、文字列を1つずつ取得し、ゆっくりとクロールする進行状況バーをユーザーに表示できます。
あなたに最高！
UPDこの機能を
思い出させてくれた Szymon Guzに感謝します。