本番データなしで本番クエリプランを生成

**[本番データなしの生産クエリプラン](https://boringsql.com/posts/portable-stats/)** Radim Marek は、2025 年 9 月に [PostgreSQL 18](https://www.postgresql.org/docs/current/release-18.html) で導入された新しい [pg_restore_relation_stats() および pg_restore_attribute_stats() 関数](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-STATSMOD) について説明しています。 PostgreSQL のクエリプランナーは、最適な実行方法を決定するために内部統計情報を利用します。これらの統計情報は、本番データと開発環境の間でしばしば異なるため、本番で使用されるクエリプランを開発環境で再現できない場合があります。 PostgreSQL の新機能により、これらの統計情報を開発環境にコピーできるようになりました。これにより、すべてのデータを事前にコピーする必要なく、本番ワークロードのプランをシミュレートすることが可能になります。 私はこの例が非常に参考になると感じました: SELECT pg_restore_attribute_stats( 'schemaname', 'public', 'relname', 'test_orders', 'attname', 'status', 'inherited', false::boolean, 'null_frac', 0.0::real, 'avg_width', 9::integer, 'n_distinct', 5::real, 'most_common_vals', '{delivered,shipped,cancelled,pending,returned}'::text, 'most_common_freqs', '{0.95,0.015,0.015,0.015,0.005}'::real[] ); これは、95% が配送済みであるステータス列の統計情報をシミュレートするものです。これらの統計情報に基づき、PostgreSQL は status = 'shipped' の場合にインデックスを使用することを決定できますが、status = 'delivered' の場合は代わりにフルテーブルスキャンを実行します。 これらの統計情報は非常に小さいサイズです。Radim 氏は次のように述べています： 統計情報のダンプは極めて小型です。数百のテーブルと数千の列を持つデータベースであっても、その統計情報ダンプは 1MB に満たないテキストファイルに収まります。一方、実際の生産データは数百 GB に及ぶ可能性があります。それを記述する統計情報はテキストファイルに収まるサイズなのです。 私は SQLite ユーザーフォーラムで、SQLite も同様の機能を提供できないかと質問しました。すると D. Richard Hipp 氏が即座に [既にあると回答](https://sqlite.org/forum/forumpost/480c5cb8a3898346) してくれました： クエリプランナーが使用する SQLite のすべてのデータ統計情報は、[sqlite_stat1 テーブル](https://sqlite.org/fileformat.html#the_sqlite_stat1_table)（または SQLITE_ENABLE_STAT4 を指定してコンパイルしている場合は [sqlite_stat4 テーブル](https://sqlite.org/fileformat.html#the_sqlite_stat4_table)）で利用可能です。このテーブルは書き込み可能であり、好きな代替統計情報を注入することができます。 クエリプランナーを制御するためのこのアプローチについては、ドキュメントでも言及されています： [https://sqlite.org/optoverview.html#manual_control_of_query_plans_using_sqlite_stat_tables](https://sqlite.org/optoverview.html#manual_control_of_query_plans_using_sqlite_stat_tables)。 また、以下のページも参照してください： [https://sqlite.org/lang_analyze.html#fixed_results_of_analyze](https://sqlite.org/lang_analyze.html#fixed_results_of_analyze)。 CLI の".fullschema"コマンドは、上記の理由により、スキーマと sqlite_statN テーブルの内容の両方を出力します。これにより、数テラバイトに及ぶデータベースファイルをロードする必要なく、テストのためにクエリの問題を再現することが可能になります。 Via [Lobste.rs](https://lobste.rs/s/o8vbb7/production_query_plans_without) Tags: [databases](https://simonwillison.net/tags/databases), [postgresql](https://simonwillison.net/tags/postgresql), [sql](https://simonwillison.net/tags/sql), [sqlite](https://simonwillison.net/tags/sqlite), [d-richard-hipp](https://simonwillison.net/tags/d-richard-hipp)

本番データなしで本番クエリプランを生成

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト