問題タブ [postgresql-performance]
For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.
sql - LIMIT 1 を指定したインデックス付き ORDER BY
テーブルの最新の行をフェッチしようとしています。created_at索引付けされた単純なタイムスタンプがあります。クエリを実行するORDER BY created_at DESC LIMIT 1と、思ったよりもはるかに時間がかかります (私のマシンでは 36k 行で約 50ms)。
EXPLAINは逆方向のインデックス スキャンを使用すると主張していますが、単純なインデックス スキャン(created_at DESC)のクエリ プランナーでは、インデックスを に変更してもコストが変わらないことを確認しました。
このユースケースを最適化するにはどうすればよいですか?
postgresql を実行して9.2.4います。
編集：
sql - 準備済みステートメントでの空の LIKE のパフォーマンスへの影響
テーブルの列にGiSTpg_trgmインデックスを設定しました。namefiles
準備されたステートメントの簡略化されたクエリは次のようになります。
$1パラメータは + ユーザー クエリ + で構成され%ます%。入力も空の文字列になる可能性があるため、%%.
「空」LIKE( %%) はパフォーマンスの低下につながりますか? その場合、新しいクエリを作成する必要がありますか、それとも問題ではありませんか?
sql - DISTINCT INNER JOIN 遅い
正常に動作する次の PostgreSQL クエリを作成しました。ただし、非常に遅いようで、結果を返すのに最大 10 秒かかることもあります。私の声明には、これが遅くなる原因があると確信しています。
このクエリが遅い理由を特定できる人はいますか?
NOT INを次のものに置き換えました。
EXPLAIN ANALYZE の結果:
sql - ネストされた結合を選択するクエリプランナーが不正確
EXPLAIN ANALYZEからこれを持っています
したがって、予想される行と実際の行にはほぼ 3 桁の違いがあり、クエリが非常に遅くなります。
default_statistics_target を 10000 に上げ、VACUUM/ANALYZE を実行して、クエリ プランナーを新しい統計で最新の状態にしました。クエリ プランナーに、より適切な結合戦略を選択させるにはどうすればよいですか?
私はpostgres 9.3.1を使用しています。私のプランナーのコスト定数はすべてデフォルトのままです。
enable_nested_loops = false を設定しましたが、クエリは実際にはあまり速く実行されませんでした。私は、クエリプランナーが返すと推定した行数と実際の行数に大きな不一致があると、最適ではないクエリプランになる可能性が高いという印象を受けました
クエリ プラン全体は次のようになります。
17GBのRAMがあります
このクエリのポイントは、ユーザーがショップにアクセスできるチケットを持つイベントを見つけることです。アクセスはさまざまな方法で決定できます。ユーザーが特定のチケットへのアクセス権を持つ部門の一部である場合、ユーザーの部門がアクセス権を持つ部門の親である場合 (ネストされたセット lft、rgt など)。会社全体にそれらのチケットへの access_right が与えられている場合、ユーザーはアクセスできます。ユーザーは、アクセス権を持つ UserGroup の一部になることができます。ユーザーには、チケットへの個別のアクセス権を与えることができます。ユーザーの会社がチケットを所有している必要があります。チケットは「凍結」または「非アクティブ」になる可能性があり、その場合、ユーザーはアクセスできません。"active_on" > Today または "inactive_on" < Today の場合、チケットは非アクティブです。ticket.hold_until > Today の場合、チケットは利用できません
私が実行しているクエリは
テーブル:
私はそれがたくさんあることを知っています、それを見てくれてありがとう
sql - 大きなテーブルでクエリを更新するのが遅い
order_item のすべての行を更新しようとしています。Status は新しく作成された列であり、order_update テーブルからの最新の値を持っている必要があります。1 つのアイテムに複数の更新を含めることができます。
PostgreSQL 9.1 を使用しています
私はこの更新SQLを持っています。
テーブルorder_itemには 800K のレコードがあります。
テーブルorder_updateには 5Mil のレコードがあります。
このSQLを最適な方法で実行するにはどうすればよいですか。更新には時間がかかることはわかっていますが、できるだけ早く更新したいだけです。
5Mil レコードでこの sql だけを実行すると、それがわかりました。
説明：
約6秒かかります。
1Mil レコードで同じ sql を実行すると:
説明:
約11ミリ秒かかります。
11 ミリ秒対 6 秒。なぜ巨大な違いがあるのですか？
少し絞り込むために、これを試します：
そして、これ：
ascとdescの大きな違いです。
解決策: インデックスを作成します:
アップデート ：