PostgreSQL

SQL実行計画の順序

tableごとにレコードを絞る？

結合

検索方式

SeqScan

デフォルト

インデックス検索

ビットマップ検索

結合方法

Nested Loop

Hash

TEMP落ちで遅くなる可能性あり

Sort Merge

TEMP落ちで遅くなる可能性

トランザクション分離レベル

デフォルトはリードコミット

反復不能読み取りやファントムリードが発生し得る

必要に応じてトランザクション分離レベルを変更する

その場合、直列化失敗の可能性が発生する

先勝ち

MySQLとはトランザクション分離レベルに関するスタンスが結構異なる

インデックス

B-tree

hash

複数列インデックス

関数インデックス

部分インデックス

権限

スキーマへの権限とスキーマ内のテーブルの権限は独立している

tableのselect等には以下のどちらの権限も必要

schemaのusage + tableのselect等

権限は3分類

database

create

database内でのschemaの作成権限

connect

temporary

schema

create

shema内でのオブジェクトの作成権限

usage

table

select等

PostgreSQLはクライアントからの要求を１つのプロセスが処理するアーキテクチャ

接続要求ごとにバックエンドプロセスがforkされ、問い合わせが処理される

MySQLはスレッドを生成するアーキテクチャ

PostgreSQLはデータをWALとデータベースファイルとしてディスクに永続化している

HDDからデータを取り出す時間とメモリからデータを取り出す時間は数百倍〜数十万台の性能差がある

データアクセス時にデータベースファイルをページ単位でメモリ上に展開している

共有バッファ

メモリの25%が目安

WALバッファはその32分の1が目安

共有バッファを使い切ると、利用されていないページをバッファから追い出す

再読み込みする場合は性能が遅くなる

OSのディスクキャッシュに残っている可能性はある（これは比較的高速）

共有メモリ

共有バッファ

テーブルやインデックスのデータをキャッシュする領域

バックエンドプロセスや自動VACUUMワーカが参照／更新する

ライタがチェックポイントのタイミングで取り出してディスクに書き込みを行う

参照の際も、共有バッファにデータがある場合は高速に処理できる

WALバッファ

WALバッファは、どのような更新を行ったかの記録であるWALをキャッシュする領域

プロセスメモリ

バックグラウンドプロセスごとに確保、利用されるメモリ

作業メモリ

クエリ実行時に利用する

ソートやハッシュテーブル等

メモリから溢れるとスワップが発生する

WALアーカイブ

参考書籍