Calendar」23日目です。PostgreSQLにはパーティショニングテーブルというものがあります。PostgreSQLを参照。(丸投げ)拙作「ふぁぼるっく」では、バックエンドのデータベースとしてPostgreSQLを採用しています。Twitterのつぶやきデータが大量に貯まり、SSDに載りきらないため、新しいデータはSSD上のテーブルスペース、古いデータはHDD上のテーブルスペースと分けて保存しています。そこで検索は横断的にやりたいということで、パーティショニングテーブルを使っています。要求は新しいもの順で表示するので、SSDだけにアクセスし、データが無ければHDDを見に行くような動きをしてほしいのです。Twitterでぼやいてみたら、9.1からは「パーティション全体のソートの最適化」が行われていることを教えてもらいました。いえば、9.1を使っていたんだった。いうことで、追試してみました。BYに入れた場合、小さい部分の受け持ちテーブルから順に見に行ってくれたりするんだろうか?いやー、この遅さなら、見てくれてないんだろうな。2011たとえば、Twitterのstatus_idの大きい順に指定件数だけ取ってきたいんだけど、古いテーブルも見てるんならやっぱり遅いよな。アプリ側で各テーブルを順に見て、指定件数分取得できるまで古いテーブルを掘り返す方が速いんだろうか。2011それってアプリ側でやることじゃないよなぁ。制約も掛けて、そのテーブルに含まれるstatus_idが分かってるんだからさ。9.1を使っているんですが、他のテーブルとJOINしたりしてるので、そのせいか全テーブルを見に行っちゃってるんですよね。条件減らして、JOINしなければうまくソートしてくれました。SQLを調整してみます。他のテーブルも含めた絞り方がキーなんですね。2011PostgreSQL.1の「パーティション全体のソートの最適化」が無効になる条件判明。A.idでB.hogeにインデックスが無い時。うー、その項2値しか入らないんよ。2011試してみた環境はPostgreSQL9.1.2、テーブル構成はこんな感じ。'社員D');親テーブルt_parent、子テーブルt_child10、t_child20。主キーはそれぞれidの社員番号。t_child10はidが10代、t_child20は20代という制約が付いている。そのほか、kindの役職にインデックスを張っている。Appendが最適化が行われた状態。2)となり、全テーブルを見に行くようになってしまいました。Appendになりました。)いろいろ試してみたのですが、テーブルの設計がかなり物を言うようです。あとは頻繁にANALYZEをかける必要がありそう。「パーティション全体のソートの最適化」が行われませんでした。プランナが賢くなるまで、もう少し辛抱のようです。中で未実装のもの」です。1.8を対象としたものです。2.0以降では、下記パラメータの1番目にホスト名というのがありません)サーバの状態監視にはzabbix!便利すぎます。負荷高いのが難点だけど、余裕があったら監視用サーバを立てるのもありかなと思う。普段はテンプレートをそのまま適用して、動いていないサービスのアイテムだけ解除していく使い方をしているのだけど、テンプレートで用意されていない物を監視したいときに、外部チェックアイテムを作成して対応した。アイテムのタイプ:外部チェックキー:get_queue_count.sh[fav_queue]などとする。このとき、zabbix_server.confのExternalScriptsに、キーで指定したスクリプトのパスを書いておく。]で括られた部分がパラメータとして渡されるのだけど、パラメータの1番目にホスト名が自動的に付けられる。fav_queueみたいに。スクリプト側では、それを考慮しておく必要がある。favlookという感じで、ホスト名は無視した。zabbix2011年7月17日日曜日PostgreSQL9.1betaでpg_upgradeしてみた。PostgreSQL9.1のベータを試用しているんだけど、beta2からCATALOG_VERSION_NOが変わっていてバイナリ差し替えが出来なかったので、pg_upgradeを試してみた。今回はbeta1からbeta3への移行。(9.0から9.1betaのときは、9.0のファイルが壊れまくっていてpg_upgradeが動かなかった)まずpg_upgradeを-cオプション付きで実行。最低限の環境が合っているか確認する。このとき、移行元のシステムは動作していて構わない。移行先のシステムは停止させておく。50913(pg_upgradeは移行先のものを使うこと)環境が異なっているとカレントディレクトリにログが吐き出されるので、それを見てライブラリの差違をなくす。チェックが終わったら、移行元、移行先の両システムを停止させて-cオプション無しでpg_upgradeを実行。このときはまったのが、ログインロールにdefault_tablespaceの設定がある場合。環境としてはroleAというロールがspaceBのオーナーであり、default_tablespace='spaceB'となっている。pg_upgradeは1.移行先にロールを作成2.ロールに付属するALTERを実行3.テーブルスペースを作成の流れて進んでいく。実行されて「そんなテーブルスペースはない」と怒られてしまう。先にテーブルスペースを作れば良いのかと、移行先にロールとテーブルスペースを作ってしまうと、1番の処理で「既にロールがある」と怒られてしまう。ロールは作らず、テーブルスペースのオーナーをpostgresにしておいても同様に「既にテーブルスペース(以下略)。結局、一時的にdefault_tablespaceを解除して実行した。pg_dumpのときみたいに、CREATE系を先に実行して、ALTER系をあとで実行するとか出来ませんかね?あと、pg_upgradeがエラーで中止されると、移行元システムの/data/global/pg_controlがpg_control.oldにリネームされて再実行できなくなるので、面倒だがpg_controlにリネームする必要がある。移行先にロールがあったら失敗するのに、と思ってみたり。移行中にpg_upgradeの進捗が分からないのも難点。残り時間までは必要無いので、対象ファイルがいくつあって、現在どこまで進んだのかが分かるだけでも気が楽だと思う。psqlを流した方が参照だけでも出来るのでpg_upgradeよりマシかも。(1)PostgreSQL9.1betaでpg_upgradeしてみた。(1)ブログ村にほんブログ。