PostgreSQL用MPPミドルウェア「Stado」の導入

PostgreSQL Advent Calendar 2012（全部俺）のDay 25です。

Advent Calendar最終日の今回は、少し大物としてPostgreSQLのMPPミドルウェア「Stado」の導入方法を紹介します。

Stado: The Open Source MPP Solution
https://launchpad.net/stado

■「MPP」とは何か

皆さんは「MPP」という言葉を聞いたことがあるでしょうか。

コンピュータの世界で「MPP」と言えば「Massive Parallel Processing」、日本語で言うところの「超並列処理」のことを指します。

Massively parallel (computing) - Wikipedia, the free encyclopedia
http://en.wikipedia.org/wiki/Massive_parallel_processing

データベースの世界で「MPP」と言うと、通常は「シェアードナッシング・アーキテクチャ」のスケーラブルな並列処理用のコンピュータアーキテクチャのことを指します。ベンダ製品で言うと、Teradata、Netezza、Greenplumなどが有名どころでしょう。

テーブルパーティショニングツール「pg_part」を使ってみる

PostgreSQL Advent Calendar 2012（全部俺）のDay 24です。

前回のエントリでは、PostgreSQLのテーブルパーティショニングの基本的なしくみとその使い方を解説してきました。

前回解説した通り、PostgreSQLのパーティショニングの機能は「理屈としては」確かに動くのですが、実際にはそのためにいろいろなコマンドを実行したりしなければならず、なかなか手間がかかるのも事実です。

■テーブルパーティションを操作するpg_partパッケージ

テーブルパーティショニングは、特に分析系の処理をしている時には便利なのですが、PostgreSQLの場合、作成や管理に結構手間がかかるため、なかなか手を出せない、という方もいるのではないでしょうか。（私も以前はそうでした）

そのため、パーティション操作のための処理を一括して実施してくれる関数群を提供するpg_partパッケージを作成しました。

uptimejp/pg_part
https://github.com/uptimejp/pg_part

今回は、このpg_partパッケージに含まれるSQL関数の使い方を紹介します。

テーブルパーティショニングを使って実現するパフォーマンス向上

PostgreSQL Advent Calendar 2012（全部俺）のDay 23です。

今回は、PostgreSQLにおけるテーブルパーティショニングの機能を取り上げます。

BigDataやデータ分析といったキーワードが多く聞かれるようになってきましたが、PostgreSQLでも大きなデータに対する集計処理のパフォーマンスを向上させるための機能が提供されています。

■「テーブルパーティショニング」

RDBMSにおける「テーブルパーティショニング」と呼ばれる機能には、ディスクへのアクセスを「局所化させる」、または「分散させる」ために提供されている機能です。これらの機能を使うことによって、大規模なデータを対象とした集計系の処理のパフォーマンスを向上させることができます。

RDBMSにおけるパーティションの種類には大きく分けて3つの種類があります。（正確には、2つとそのコンビネーションですが）

・レンジパーティショニング

レンジパーティショニングというのは、連続的な値（と連続的な意味）を持つカラム（日付など）をパーティションキー（分割のキー）として指定することで、テーブルスキャンなどのアクセスを「局所化」させることを目的としたパーティショニングです。「垂直方向のパーティショニング」と呼ばれることもあります。

データブロックサイズの変更と分析系クエリへの性能影響（SSD編）

PostgreSQL Advent Calendar 2012（全部俺）のDay 22です。

最近、PostgreSQL上でデータ分析処理をよく行うようになってきました。また、いろいろなところでSSDも使うようになってきました。

PostgreSQLとデータ分析とSSD、という組合せを考えた時、どのようにチューニングするのが望ましいのか、あるいはどのようなチューニングができるのか、個人的にはまだまだ試行錯誤中だったりします。

SSDはハードディスクと比べてブロックサイズが大きいという特徴があります。また、DWH系のデータベースでは大きいブロックサイズを使うとパフォーマンス上のメリットがある、と言われています。

今回は、SSD上でPostgreSQLを使ってデータ分析系の処理を行う時に、データブロックのサイズを変えるとクエリのパフォーマンスにどのような影響を与えるのか、実際にクエリを実行しながら見ていきます。

■ブロックサイズの変更方法と確認方法

PostgreSQLでデータブロックのサイズを変更するには、PostgreSQLのブログラムバイナリをビルドする際にブロックサイズを指定する必要があります。

具体的にはconfigureスクリプトのオプションに--with-blocksizeというオプションを与えて、ここでブロックサイズを指定します。

pgTAPを使ってPostgreSQL上でデータベースの単体テストを行う

PostgreSQL Advent Calendar 2012（全部俺）のDay 21です。

PostgreSQLはその拡張性の高さが大きな特徴となっており、「プロシージャ言語」、いわゆる「PL」として、一般的なSQLやPL/pgSQLだけではなく、PerlやPython、RubyやV8なども使うことができます。

これらのPLを使うと、自分の馴染んだ言語、特に広く一般的に使われているLLで簡単にロジックを書き、これをデータベース内で実行することができるようになります。このことが、最近PostgreSQLがアプリケーション開発プラットフォームとして注目を集めてきている大きな理由の一つでしょう。

一方で、ロジックを実装するということは、そのロジックが正しく動くことを確認するためのテストを行わなければなりません。

というわけで、今回はPostgreSQL上で開発を行う場合にユニットテストに使えるツール「pgTAP」を紹介します。

■単体テストツール「pgTAP」とは

pgTAPは、David E. Wheeler氏によって開発されているPostgreSQL用の単体テストツールです。

pgTAP: Unit Testing for PostgreSQL
http://pgtap.org/

単体テストを実行するのに必要なさまざまなSQL関数を提供しており、テストスクリプト内でこれらのSQL関数を使うことで、スキーマの構造やプロシージャ（ユーザ定義関数）のロジックの正しさなどをテストすることができます。

次期バージョンの9.3で実装された更新可能ビューを試してみる

PostgreSQL Advent Calendar 2012（全部俺）のDay 20です。

先日、ネット上でも少し話題になっていましたが、開発中のPostgreSQLの次バージョン（9.3）に「更新可能ビュー」をサポートするコードがコミットされました。

pgsql: Support automatically-updatable views.
http://archives.postgresql.org/pgsql-committers/2012-12/msg00154.php

今回はこの更新可能ビューについて、その制約なども含めてどのようなものなのかを見てみたいと思います。

なお、今回は開発中のバージョンで試しますので、試してみたい方はPostgreSQLのGitレポジトリからソースコードを取得して自身でビルドしてください。

Working with Git - PostgreSQL wiki
http://wiki.postgresql.org/wiki/Working_with_Git

■「更新可能ビュー」とは

「更新可能ビュー」とはどういった機能でしょうか。

RDBMSにおけるビューのしくみを理解している方は、それを思い浮かべていただければ分かるかと思いますが、ビューの定義が「十分に簡単」である場合、ビューに対するINSERTやUPDATE、DELETE処理は、元テーブルに対する更新処理に書き換えることが可能になるはずです。

この「ビューに対する更新処理を、元テーブルに対する更新処理へ自動的に書き換える」という機能が、「automatically updatable、自動的に更新できる」ビューと言われる機能になります。

PostgreSQLのストレージアーキテクチャ（FILLFACTOR編）

PostgreSQL Advent Calendar 2012（全部俺）のDay 19です。

昨日までのエントリで、PostgreSQLの追記型アーキテクチャの基本的な仕組みと、「追記型であるがゆえの課題」にどのように対処しているのかを解説してきました。

ストレージアーキテクチャ小咄シリーズの最終回である今回は、「FILLFACTOR」と呼ばれる仕組みについて、その動作している様子を見ながら解説します。

（他のRDBMSをご存じの方のボキャブラリーに直すと、OracleやDB2で言うところのPCTFREE、SQL ServerのFILLFACTORと似たような役割の機能になります。）

■ブロックに空き領域が無い時の更新処理

ブロック内部が既にいっぱいで空き領域が無い時にレコードを追加または更新しようとした場合、特に前々回に解説したPage Pruningを実施しても空き領域が無かった場合、PostgreSQLではどのように処理されるのでしょうか。

結論から言うと、同一ブロック内に新しいレコードを追記する領域が無いため、他のブロックに新しいレコードを書き込むことになります。

テーブルのブロック構造を思い出しながら、具体的な例で見てみましょう。

PostgreSQLアーキテクチャ入門（INSIGHT OUT 2011） from Uptime Technologies LLC (JP)

PostgreSQLのストレージアーキテクチャ（HOT編）

PostgreSQL Advent Calendar 2012（全部俺）のDay 18です。

前回のエントリでは、PostgreSQLのストレージアーキテクチャのうち、特にPage Pruningについて実際の動作状況を見ながら、その仕組みを解説しました。

ここまではテーブルのみの解説をしてきましたが、実際には（ほとんどのテーブルには）インデックスもありますので、レコードを更新する場合にはインデックスについてのケアも必要になります。

というわけで、今回はレコードに対する更新が行われている間に、インデックスがどのように動作しているのかを、具体的な動作例を交えて見てみます。

■インデックスの内部構造

B-Treeのリーフノードの内部構造は以下のようになっています。

PostgreSQLアーキテクチャ入門（INSIGHT OUT 2011） from Uptime Technologies LLC (JP)

前々回のストレージアーキテクチャの基本編で、pageinspectというcontribモジュールを紹介しました。

PostgreSQLのストレージアーキテクチャ（Page Pruning編）

PostgreSQL Advent Calendar 2012（全部俺）のDay 17です。

昨日のエントリでは、「ストレージアーキテクチャ（基本編）」ということで、PostgreSQLの内部でディスクがどのように使われているのか、その基本を解説しました。そして、PostgreSQLの更新処理で「新しいレコードを追記し、古いレコードからチェーンのようにつなぐ」という処理をしている様子を実際に観察しました。

今回は、この「追記型のストレージアーキテクチャ」の持つ課題を克服するために、どのような工夫がされているのかを実際の動作を見ながら解説します。

■追記型ストレージにおけるファイルの肥大化とその抑制

PostgreSQLに対する指摘として、「この追記型の更新処理がデメリットである。更新が増えるとレコードがどんどん増えていくのが弱点である」という指摘があります。

原則論としては、確かに更新処理を連続して行うとレコードが追記されてデータのサイズが大きくなっていくのですが、実際の実装はそんなに単純なものではなく、データサイズが増えないように随所に工夫がされています。

PostgreSQLのストレージアーキテクチャ（基本編）

PostgreSQL Advent Calendar 2012（全部俺）のDay 16です。

PostgreSQLのアーキテクチャやパフォーマンスを議論する際、「ストレージ（ファイル）が追記型のストレージアーキテクチャを採用している」ということは、PostgreSQL特有の大きな特徴として認識している方も多いでしょう。

少し前にも、ネット上でPostgreSQLと他のRDBMSのストレージのアーキテクチャの違いについて話題になったこともありました。

PostgreSQLとMySQLはどちらかに明確な優位性がありますか？ - QA@IT
http://qa.atmarkit.co.jp/q/2395

優位性云々の議論はとりあえず置いておくとして、まずはPostgreSQLの実際の仕組みをきちんと理解するために「追記型のストレージ」というものがどのように動いているのかを覗いてみます。

■「追記型のストレージアーキテクチャ」とは

PostgreSQLにおける「追記型のストレージアーキテクチャ」というのは、簡単に言えば、「レコードの更新処理を行う際に、ブロック内の以前のレコードを上書きするのではなく、別のレコードとして作成する」という仕組みのことです。

tablelogでテーブルの更新差分を取得する

PostgreSQL Advent Calendar 2012（全部俺）のDay 15です。

PostgreSQLに限らず、RDBMSにおいて「特定のテーブルの更新差分だけを取得したい」というのは、DBAの夢であると言えます（よね？）。

トランザクションログの中には当然ながら「更新情報」が記録されているわけですが、それを再利用可能な形で取り出す方法が無く、涙で枕を濡らした思い出を持つDBAも多いことでしょう。多分。

もう少し分かりやすく申しますと、PostgreSQLのメジャーバージョンアップの際などにはpg_dumpによるexport/importが必要となるわけですが、データ量が多くなって来ている今、データのexportにも時間がかかりますし、24x365のシステムも増えていますので、移行している間にもデータの更新が発生してしまいます。

なので、こういった作業の合間に発生する更新情報（少ないとは言え）を、保存しておいて、後から再利用できると便利ですよね？　ね？　という話であります。

■tablelogモジュール

というわけで、今回はPostgreSQLにおいて、テーブルの更新差分を取得する方法をご紹介します。

今回はtablelogというモジュールを使います。

PgFoundry: Table Audit: Project Info
http://pgfoundry.org/projects/tablelog/

pg_receivexlogでリアルタイムバックアップを取得する

PostgreSQL Advent Calendar 2012（全部俺）のDay 14です。

ご存じのように、PostgreSQLは9.0から標準でレプリケーションが実装されました。それに加えて9.2では、pg_receivexlogというコマンドが追加されました。

pg_receivexlog
http://www.postgresql.jp/document/9.2/html/app-pgreceivexlog.html

pg_receivexlogは、ネットワーク経由でトランザクションログを受信、ログのアーカイブを作成・蓄積していくことを可能にするコマンドです。このコマンドを使うことによってスタンバイサーバを稼働していなくても、レプリケーションの機能を使ってリアルタイムバックアップを取得することができるようになります。

pg_receivexlogの基本的な仕組みについては、ストリーミングレプリケーションの開発者のFujii氏の以下のスライドを参照してください。

PostgreSQLレプリケーション徹底紹介 from Masao Fujii

今回は、このpg_receivexlogコマンドを使ってアーカイブログを別サーバに蓄積し、それを使ってリカバリができるのか、というところを検証してみようと思います。

なお、Fujii氏のエントリと盛大に被ってしまったのですが、ここでは気にしないことにします。氏のエントリも併せて読むと二倍楽しめるかもしれません。

AWSでそこそこセキュアにPostgreSQLインスタンスを立ち上げる

（4/5追記）アクセス管理関連の脆弱性が発見されています。

• 【リリース情報】セキュリティリリース（9.2.4、9.1.9、9.0.13、8.4.17）が出ています
  http://pgsqldeepdive.blogspot.jp/2013/04/securityrelease.html

バージョン9.2.3、9.1.8、9.0.12、8.4.16およびそれより前のバージョンをお使いの場合はアップグレードしてください。特にクラウド環境で利用する際にはご注意ください。

---

PostgreSQL Advent Calendar 2012（全部俺）のDay 13です。

クラウドが大流行中です。（個人的に）

いろいろ試したり、ちょっとデータを突っ込んで分析したり、といった用途に使う場合には、クラウド上に自分専用のPostgreSQLが動いていると何かと便利です。

PaaSサービスを使うのも良いのですが、IaaS上に自分でPostgreSQLをインストールした方が自由度は高くなりますので、今回はAmazon EC2上にPostgreSQLをインストールして、自分専用のサーバとして使う設定をしてみます。

なお、インターネット上をデータが流れる関係上、多少、セキュリティに配慮した設定を行おうと思います。（とは言っても、ポート番号を変えてSSL接続を行うだけですが・・）

前提として、インターネット上のサーバの任意のポートに対してTCP接続を張れることが必要です。ファイヤーウォールなどでネットワーク接続が制限されている場合にはこの方法は使えません。

■Amazon EC2でインスタンスを立ち上げる

まず、Amazon EC2でインスタンスを立ち上げます。

EC2のセットアップから説明していると非常に長くなるため詳細は省きますが、今回は以下の設定で立ち上げます。

HinemosでPostgreSQLの性能を監視する

PostgreSQL Advent Calendar 2012（全部俺）のDay 12です。

「最近（個人的に）可視化ブームが訪れている」という話を前回のエントリで書きました。

パフォーマンスに関連するデータを可視化してくれるツールにはさまざまな種類があり、いろいろと目移りしてしまうのですが、今回はオープンソースの運用管理ツール「Hinemos」でPostgreSQLのパフォーマンス情報の可視化を行う方法を紹介します。

■HinemosとPostgreSQL性能監視

Hinemosはオープンソースの統合運用管理ソフトウェアです。システム監視機能やジョブ管理機能の機能等を備えており、システムの運用管理をサポートしてくれるソフトウェアになります。

Hinemos：コンピュータ、システム、ネットワークの運用管理を実現するオープンソースソフトウェア(OSS)
http://www.hinemos.info/

先日、この「Hinemosへのアドオン」という形で、PostgreSQLの性能情報を取得・蓄積・可視化・監視することができるツールを作成しました。

Hinemos PostgreSQL性能監視オプション
http://www.uptime.jp/ja/products-services/hinemos-postgres-addon/

このツールは、簡単に言うと「少し大きめのスクリプト」なのですが、オープンソースで公開されており、このスクリプトとHinemosを組み合わせることによって、比較的簡単にPostgreSQLの性能情報を可視化することができます。

GrowthForecastでパフォーマンス情報を可視化する

PostgreSQL Advent Calendar 2012（全部俺）のDay 11です。

最近、ちょっとした可視化ブームが訪れております（個人的に）。

運用管理を可視化するツールやプラグインもいろいろと公開されている昨今ですが、個人的にはちょっと前から「GrowthForecast」というツールが気になっていましたので、今回はこれを使ってPostgreSQLを可視化してみようと思います。

■「GrowthForecast」とは何か

「GrowthForecast」は @kazeburo氏 の開発したグラフツールです。単独でWebサーバとして動作し、WebAPIを経由して可視化すべきデータの登録を受け付け、HTTPリクエストでグラフ化された画像データを取得することができるソフトウェアです。

GrowthForecast - Lightning fast Graphing / Visualization
http://kazeburo.github.com/GrowthForecast/

一般的な運用監視ツールは、長期的に運用監視する場合には便利でいいのですが、セットアップに手間がかかるし使いこなすのもいろいろ大変だということで、その辺りを簡単に使えるようにしたい、というツールです。

というわけで、今回はこのGrowthForecastを使ってPostgreSQLの統計情報を可視化してみます。

Rを使ってパフォーマンス統計情報を可視化する

PostgreSQL Advent Calendar 2012（全部俺）のDay 10です。

前回までに、PostgreSQLのパフォーマンスデータを取得・蓄積し、それをSQLを用いて解析する方法を紹介してきました。

しかし、増えていくデータを活用して人間が何らかのアクションを取るためには、データを何らかの形で「可視化」して、人間が容易に読解・解釈できる形に変更する必要があります。

今回は解析結果を可視化する方法について簡単に紹介します。ツールとしては、オープンソースの統計処理ソフトウェアである「R」を利用します。

■R、および関連パッケージのインストール

まず、RのサイトからRのバイナリパッケージをダウンロードします。

The R Project for Statistical Computing
http://www.r-project.org/

ウィンドウ関数を使ってブロック読み込み量の推移を見る

PostgreSQL Advent Calendar 2012（全部俺）のDay 9です。

前回は、PgPerfパッケージを使って、PostgreSQLの各種統計情報のスナップショットを取得・保存する方法を解説しました。

今回は、その保存したデータを分析する方法をご紹介します。

お題は「データベースのブロック読み込み発生の推移を分析する」です。

■使用するスナップショットテーブル

今回使用するスナップショットテーブルは、

• pgperf.snapshot
• pgperf.snapshot_pg_stat_database

の2つのテーブルです。前者には、スナップショットIDと取得日時が、後者にはデータベースごとのブロック読み込みの統計情報のスナップショットが保存されています。

SELECT * FROM pgperf.snapshot LIMIT 5;
SELECT * FROM pgperf.snapshot_pg_stat_database LIMIT 5;

これらのテーブルを分析することで、データベースのブロック読み込みの推移を確認してみます。

なお、これらのテーブルの構造の詳細についてはPgPerfパッケージのユーザーマニュアルを参照してください。

PgPerfパッケージユーザーマニュアル
http://www.uptime.jp/go/pgperf-snapshot/

パフォーマンス統計情報のスナップショットを取得する

PostgreSQL Advent Calendar 2012（全部俺）のDay 8です。

今日は、PostgreSQLの統計情報を網羅的に収集・蓄積するPgPerfパッケージの紹介をします。

このパッケージは、本日リリースしたものです。

snaga/pgperf-snapshot
https://github.com/uptimejp/pgperf-snapshot

■PostgreSQLの統計情報の記録と監視

PostgreSQLでは、動作についての内部の情報を取得するために、さまざまなシステムビューやSQL関数があります。

いまさら聞けないPostgreSQL運用管理 from Uptime Technologies LLC (JP)

統計情報コレクタ
http://www.postgresql.jp/document/9.0/html/monitoring-stats.html
システム管理関数
http://www.postgresql.jp/document/9.0/html/functions-admin.html

この情報を取得することで、PostgreSQLの内部でどのような処理が行われているのかを知ることができます。

一方で、これらの内部の統計情報は時々刻々と変化していくため、データベースサーバの運用という観点で見る場合には、きちんと記録をしておく必要があります。

pg_buffercacheで共有バッファを覗いてみる

PostgreSQL Advent Calendar 2012（全部俺）のDay 7です。

Day 1のエントリにも少し出てきましたが、PostgreSQLを始めとするRDBMSは、共有バッファ（データベースバッファと呼ばれることもある）にデータを一時的に保持して、ディスクI/Oを削減することでパフォーマンスの向上を実現しています。

普段はなかなか窺い知ることのできない共有バッファの内容ですが、今回はそのPostgreSQLの共有バッファの中身を見てみることにします。

■PostgreSQLの共有バッファ

PostgreSQLの共有バッファの簡単な解説については、改めて以下のスライドを見ていただければと思います。

PostgreSQLアーキテクチャ入門（PostgreSQL Conference 2012） from Uptime Technologies LLC (JP)

PostgreSQLのテーブルやインデックスファイルは、8kBのブロック単位で構成されており、SQLの処理の時に実際に必要とされるブロックだけを読み込むことによって、共有バッファ上でデータの読み書きを可能にしているのです。

pg_filedumpでテーブル／インデックスファイルを覗いてみる

PostgreSQL Advent Calendar 2012（全部俺）のDay 6です。

PostgreSQLは、テーブルやインデックスなどは、それぞれ個別のファイルになっています。通常、これらのファイルを直接見ることはなく、あくまでもPostgreSQLのサーバに対してクエリを投げて、PostgreSQLのバックエンドプロセスがテーブルやインデックスなどのファイルを読み書きすることになります。

PostgreSQLアーキテクチャ入門（PostgreSQL Conference 2012） from Uptime Technologies LLC (JP)

但し、何らかの異常（または単なる好奇心）が発生した場合、テーブルやインデックスのファイルそのものを直接見てみたくなることがあります。

そのような場合のために作成されているツールが "pg_filedump" と呼ばれるユーティリティです。

PostgreSQL版topコマンド「pg_top」を使ってみよう

PostgreSQL Advent Calendar 2012（全部俺）のDay 5です。

Unix系プラットフォームでシステムの開発または管理をしている方は、topというコマンドをご存じだと思います。システムのロードアベレージを見たり、実行中の各プロセスの負荷を見たりするアレですね。

実は、PostgreSQLにも "pg_top" という似たような機能を実現するユーティリティがあります。今回はその使い方を簡単に御紹介します。

■pg_topとは

pg_topはPostgreSQL関連の開発をしているMark Wong氏によって開発されたツールです。

PostgreSQL top (pg_top): Project Home Page
http://ptop.projects.pgfoundry.org/

もともとはpgFoundryでホストされたプロジェクトでしたが、ソースコードの最新版は現在はGitHubにあるようです。

markwkm/pg_top
https://github.com/markwkm/pg_top

pgBadgerでSQLログを分析する

PostgreSQL Advent Calendar 2012（全部俺）のDay 4です。

負荷試験や本番稼働中のデータベースサーバでは、通常さまざまな種類のSQLが実行されています。

昨日紹介したpg_stat_statmentsシステムビューは、PostgreSQLの内部でSQLの実行状況を積算することのできるモジュールでしたが、「pg_stat_statementsを使うには制約が・・・」というケースもあるでしょう。

PostgreSQLには実行しているSQL文をサーバログに出力する機能があります。SQL文だけでなく実行時間なども出力することができるため、このサーバログを集計することによって、どのようなSQLがどれくらい実行されていて、どのSQLにパフォーマンス上の問題がありそうなのか、といったことを絞り込んでいくことができます。

■SQLログ解析ツール「pgBadger」

サーバログを集計するツールとしてはいくつかあるのですが、今日は「pgBadger」というツールを紹介します。

pgBadger
http://dalibo.github.com/pgbadger/

実行が遅いSQL文をpg_stat_statementsで抽出する

PostgreSQL Advent Calendar 2012（全部俺）のDay 3です。

3日目となる今回はSQL文の実行状況を解析するツールとしてpg_stat_statementsを使ってみます。

■SQLパフォーマンスをどのように分析するか

特定のSQL文が遅いことが判明している場合は別ですが、通常、SQLのパフォーマンス分析を行う場合には、「どのSQL文が問題なのか」というところから調査します。その時の判断の軸としては、主に以下の2つがあります。

・実行回数の多いSQL文
・実行時間の長いSQL文

特定のSQL文を修正して得られるパフォーマンス向上の成果は、

・1つのSQL文の改善量×実行回数

となります。

例えば、1回実行するのに1秒かかるSQL文を1万回実行すると、トータルで1万秒となりますが、一回あたりの実行時間を0.5秒に短縮できればトータルの実行時間としては1万秒から5000秒に短縮されることになります。

このようにして、「クエリ1回の実行時間×クエリの実行回数」の大きいものから改善してくと、SQLチューニングに投入する費用対効果（時間も含む）が高くなります。

contribモジュールを使ってみよう

PostgreSQL Advent Calendar 2012（全部俺）のDay 2です。

今日はcontribモジュールの使い方についてです。

■contribモジュールとは

PostgreSQLには「contrib」と呼ばれるモジュールがあります。

これは、PostgreSQLのソースコードと一緒に配布されているものの、明示的にコンパイルしてインストールしないとデフォルトではインストールされないという、PostgreSQL周辺の拡張モジュールや便利ツールです。

以下のような感じで、ソースディレクトリの中のcontribというディレクトリ内にいろいろと並んでいます。

[snaga@devsv02 postgresql-9.0.8]$ ls
aclocal.m4  config.status*  contrib/   GNUmakefile     INSTALL   src/
config/     configure*      COPYRIGHT  GNUmakefile.in  Makefile
config.log  configure.in    doc/       HISTORY         README
[snaga@devsv02 postgresql-9.0.8]$ cd contrib/
[snaga@devsv02 contrib]$ ls
adminpack/         fuzzystrmatch/      pgbench/             seg/
auto_explain/      hstore/             pg_buffercache/      spi/
btree_gin/         intagg/             pgcrypto/            sslinfo/
btree_gist/        intarray/           pg_freespacemap/     start-scripts/
chkpass/           isn/                pgrowlocks/          tablefunc/
citext/            lo/                 pg_standby/          test_parser/
contrib-global.mk  ltree/              pg_stat_statements/  tsearch2/
cube/              Makefile            pgstattuple/         unaccent/
dblink/            oid2name/           pg_trgm/             uuid-ossp/
dict_int/          pageinspect/        pg_upgrade/          vacuumlo/
dict_xsyn/         passwordcheck/      pg_upgrade_support/  xml2/
earthdistance/     pg_archivecleanup/  README
[snaga@devsv02 contrib]$

この一覧はオフィシャルマニュアルでは「付録 F. 追加で提供されるモジュール」に記載されています。 このcontribのモジュールを使いこなせるかどうかで、PostgreSQLの便利度は大きく変わってきますので、今回はこのcontribモジュールの使い方を解説します。

PostgreSQL初期設定これだけは変えておこう

PostgreSQL Advent Calendar 2012（全部俺）のDay 1です。

初日は、まずPostgreSQLを使い始める際の基本的なお作法である初期設定について簡単にまとめてみます。

PostgreSQLは、パラメータの設定を変更せずにデフォルトの設定のまま使い始めても、もちろん動くことは動くのですが、後からいろいろと問題が出てくることもありますし、特に性能関連のパラメータのデフォルト値はあまりに小さく、チューニング云々以前の問題だったりします。

というわけで、私が普段PostgreSQLをインストールして使い始める時、開発機であってもいくつかパラメータを初期設定するようにしています。

使い始める前に設定から入るのは確かに面倒なのですが、最初に設定が必要なパラメータは少数（今回紹介するのは5つ）ですので、まずは最初に必要最低限の設定をしてから使い始めましょう、というのが本エントリの趣旨です。

■設定するパラメータの種類

最初に設定を行うPostgreSQLのパラメータには、大きく分けて

・メモリ（バッファ）関連
・チェックポイント関連
・サーバログ関連

というカテゴリがあります。これらについて以下に順番に解説していきます。