私は次のクエリでPostgresを使用しています:
select count(*) from image;
このテーブルの主キーはインクリメントされていません。これは、テーブルに保存されている画像の一意のシリアル番号です。私たちのアプリは、データベースにすでに記録されている画像を取り込もうとすることが多いため、主キー/シリアル番号は、それらが一度だけ記録されることを保証します。
代わりに、インクリメントする主キーを使用するべきだったのではないかと考えています。データベースには1,259,369個の画像があり、カウントクエリの実行には約7分かかります。
アプリがこのテーブルから画像を削除することは決してありません。主キーが増えると、テーブル内の行数と同じになる最後のIDの値を確認できるようになります。
一般的に、exactカウントが必要ない場合、muchより高速な方法:
SELECT reltuples::bigint AS estimate
FROM pg_class
WHERE oid = 'image'::regclass;
実際のところ、同時書き込みアクセスのあるDBでは、every数は推定値です。これは、数を取得するとすぐに古くなる可能性があるためです。
しかし、 @ a_horseがコメント のように、DBに何か問題があります。 最悪の場合、100万を数えるのに数秒以上かかるべきではありません。
あなたのapp will never delete images from this table
は、デッド行が多くないはずなので、これをさらに疑わしくします。 (または、たくさん更新していますか?)大量の死んだタプルが遅くなる可能性があります-VACUUM
を呼び出します。通常、 autovacuum がこれを処理します。有効にしましたか? (これは、最新のPostgresのデフォルトです。)
死んだタプルを確認します。
Pg_stat_user_tablesを使用すると、PostgreSQLテーブルの行数を確認できます。
SELECT
schemaname
,relname
,n_live_tup AS EstimatedCount
FROM pg_stat_user_tables
ORDER BY n_live_tup DESC;