問題タブ [postgresql-performance]

100万レコードのユーザーテーブルがあります。

postgres9.1dbに対して実行されている次のクエリがあります。

pgAdmin 3を使用すると、このSQLは25行を返すのに7120msかかります。'ORDER BY guest = false、fname ASC'を削除すると、クエリにかかる時間はわずか31ミリ秒です。

私は次のインデックスを持っています：

何か案は？ありがとうございました！

Explainで更新

私は現在次のものを持っています：

fname次のように、ユーザーのイニシャルでユーザーのリストを照会できます。

これは、次のインデックスのおかげで高速です。

私が今やりたいのは、文字のAZで始まらないすべてのユーザーを照会できるようにすることです。私はこれをそのように機能させました：

しかし、問題は、このクエリが非常に遅く、最初のクエリを高速化するためにインデックスを使用していないように見えることです。2番目のクエリ（az以外）をエレガントに高速化する方法についての提案はありますか？

Rails3.2でPostgres9.1を使用しています

ありがとう

私は EXPLAIN ANALYZE の結果を見ることにあまり慣れていません。クエリが遅すぎるという大きな問題があります。説明クエリの結果を解釈する方法を調べてみましたが、何を探すべきか、何が間違っているのかまだわかりません。どこかで大きな赤い光が点滅しているように感じますが、見えません。

したがって、クエリは非常に単純で、次のようになります。

そして、このような結果：

ちょっとした背景: 私は Postgresql 9.1.6 を使用しており、Herokus 専用データベースで実行しています。私のデータベースには約7,5GbのRAMがあり、テーブルcarsには3,1Mの行が含まれ、約2,0Mの行にはsales_state = 'onsale'があります。テーブルには 170 列あります。使用するインデックスは次のようになります。

大きな明らかな問題を見ている人はいますか？

編集：

pg_relation_size: 2058444800 pg_total_relation_size: 4900126720

pg_relation_size: 46301184

平均: 636.9732567210792995

制限なし:

postgresqlとpsycopg2を使用して小さな在庫システムを構築しました。コンテンツの集計された要約/レポートを作成したい場合を除いて、すべてがうまく機能しますが、count（）と並べ替えのためにパフォーマンスが非常に悪くなります。

DBスキーマは次のとおりです。

他にもいくつかのフィールドがありますが、それらは関係ありません。

2つの異なるレポートを抽出したい：-アイテム数が多いすべてのホストのリスト、カウントの高いものから低いものへ-ホストの数が多いすべてのアイテムのリスト、カウントの高いものから低いものへの順序

私は目的のために2つのクエリを使用しました：

ホスト数のあるアイテム：

アイテム数のあるホスト：

問題は、データを返す前にクエリが5〜6秒間実行されることです。これはWebベースのアプリケーションであるため、6秒は受け入れられません。データベースには、約5万のホスト、1000のアイテム、および400 000のホスト/アイテムの関係が大量に存在し、アプリケーションを使用する場合（または使用する場合）に大幅に増加する可能性があります。

遊んだ後、「ORDER BY count DESC」の部分を削除することで、両方のクエリが遅延なく即座に実行されることがわかりました（クエリを完了するのに20ミリ秒未満）。

これらのクエリを最適化して、遅延なく結果を並べ替えることができる方法はありますか？さまざまなインデックスを試していましたが、カウントが計算されるので、これにインデックスを利用することができます。postgresqlでのcount（）の実行が遅いことを読みましたが、問題の原因となっている並べ替えです...

私の現在の回避策は、上記のクエリを1時間ごとのジョブとして実行し、結果を新しいテーブルに入れて、カウント列にインデックスを付けてすばやく検索することです。

私はPostgresql9.2を使用しています。

更新：注文どおりのクエリプラン:)

更新：この質問に対するすべての回答は、Postgresがどのように機能するかを学び理解するのに非常に役立ちます。この問題に対する明確な解決策はないようですが、あなたが提供してくれたすべての優れた回答に本当に感謝しています。Postgresqlでの今後の作業でそれらを使用します。たくさんの人に感謝します！

conttagtable(t) とcontfloattable(cf)の 2 つのテーブルがあります。T には約 43k 行あります。CFは90億以上あります。

tagindex両方のテーブルの列の両方のテーブルにインデックスを作成しました。この列は、 の一意の識別子および へのconttagtable外部キーと考えることができます。このデータは、あたかもaであるかのように、両方のテーブルの列によって論理的に関連付けられていますが、もう一方のテーブルに PK または外部キーを明示的に作成しませんでした。データはマイクロソフトのアクセス ダンプから取得されたものであり、tagindex が一意であると信頼できるかどうかわからなかったため、「一意性」は強制されません。conttagtableconfloattabletagindexconttagtable.tagindexPRIMARY KEYcontfloattable.tagindexFOREIGN KEY (tagindex) REFERENCES conttagtable(tagindex)

データ自体は非常に大きいです。

contfloattable各 の 15 分contfloattable.dateandtime間隔ごとに、 から任意に選択された単一の行を取得する必要がありますconttagtable.tagid。したがって、contfloattable特定のtagidに 30 分間にわたる 4000 個のサンプルがある場合、0 ～ 14 分の範囲のサンプルと 15 ～ 30 分の範囲のサンプルが必要です。15 分の範囲内の任意の 1 つのサンプルが許容されます。最初、最後、ランダム、何でも。

簡単に言えば、15 分ごとにサンプルを取得する必要がありますが、t.tagname ごとに 1 つのサンプルしか取得できません。現在、サンプルは 5 秒ごとに記録されており、データは 2 年間に及びます。これはビッグデータの問題であり、SQL に関しては私の頭をはるかに超えています。私がグーグルやSOで検索して試した時間間隔の解決策はすべて、実用的ではないほど長いクエリ時間を生み出しました。

• インデックスは高速結合に十分ですか? （時間間隔部分を省略した場合に表示されます）
• 他のインデックスを追加することでメリットがありますか?
• 上記の目標を達成するための最良/最速のクエリは何ですか?

スキーマといくつかのサンプル データを含む SQLFiddle を次に示します: http://sqlfiddle.com/#!1/c7d2f/2

スキーマ:

私が見たい出力は次のようなものです：

...などなど...

Clodoaldo が示唆しているように、これは私の最新の試みですが、スピードアップするための提案はありますか?

上記のクエリプラン: http://explain.depesz.com/s/loR

Postgres 9.1 を使用していますが、クエリの実行が非常に遅いです。

クエリ:

結果：

ご覧のとおり、これには約 11 秒かかります。このクエリのパフォーマンスを最適化するためにインデックスを追加するにはどうすればよいですか?

PostgreSQL 9 データベースには、PK (oid 対応) であるシリアル フィールド X とその他のフィールドを含むテーブルがあります。

そのテーブルで postgres の pgadmin を使用すると、クエリに 30 秒かかります。

同じフィールド X に一意のインデックスを追加すると、pgadmin の同じクエリに 3 秒かかります。

PK は暗黙的にインデックスです: http://www.postgresql.org/docs/current/static/indexes-unique.html

では、なぜ明示的なインデックスが違いを生むのでしょうか?

これは pgadmin の問題ですか?

PK フィールドに明示的なインデックスが必要ですか?

POSTGRESQL9.2で最適化するためにこのクエリが与えられます。

私の学校の割り当ての一部として。

それぞれのテーブルにこれらのインデックスを作成しました：items(category)-> 2ndary b + tree、bids(item_id)-> 2ndary b + tree、categories(id)->ここでのプライマリインデックス、

奇妙な部分は、PostgreSQLがItems、Categories、Bidsテーブルを順次スキャンしていることです。を設定するenable_seqscan=offと、インデックス検索は以下の結果よりも恐ろしいことがわかります。

PostgreSQLでexplainを実行すると、これが結果になります。重要であるため、インデントを削除しないでください。

Explain.depesz.comでこの計画を参照してください。

なぜこれが発生するのか、つまりインデックスがシーケンシャルスキャンと比較してクエリをひどく遅くする理由を知りたいだけです。

編集：postgresqlのドキュメントを読むことで、いくつかのことを発見できたと思います。Postgresqlは、テーブル内のすべての行を取得する必要があると予測したため、入札やアイテムなどの一部のテーブルでseqスキャンを実行することを決定しました（実際の時間の前の括弧内の行数と実際の時間部分の行数を比較してください） ）。シーケンシャルスキャンは、すべての行を取得するのに適しています。その部分では何もできません。

の追加のインデックスを作成しましcategories(name)た。以下の結果は私が持っているものです。どういうわけか改善されましたが、ハッシュ結合がネストされたループに置き換えられました。理由の手がかりはありますか？

それがより良い場合は、ここで計画を見てください。

category（id）とにインデックスを作成することで、なんとか114062.92に減らすことができましたitems(category)。Postgresqlは両方のインデックスを使用して114062.92のコストを達成しました。しかし、現在、postgresqlはインデックスを使用せずに私とゲームをしています！なぜそんなにバグがあるのですか？

私はPostgresqlを使用しています。関数の実行にかかる時間をテストしたいと思います。この関数は数ミリ秒しかかからないので、正確な数値を取得するために、何千回もループで呼び出したいと思います。

MySQLには、これを行うためのBENCHMARK（）関数があります。同等のものはありますか、それともこれを行うためにループ付きのプロシージャを作成する必要がありますか？

現在、以下のSQL Selectステートメントに対して次のインデックスがあります。それにもかかわらず、クエリはまだ遅いようです (10.000 レコード)。おすすめはありますか？

1. インデックスのカテゴリ ID
2. index delivery_date
3. product_id、product_name のインデックス

ここに私のDDLがあります：

および SQL:

どんな助けでも大歓迎です。

EXPLAIN ANALYZE の出力の下: