From i-kaori ＠ sraoss.co.jp Mon Feb 6 11:59:16 2012 From: i-kaori ＠ sraoss.co.jp (Kaori Inaba) Date: Mon, 6 Feb 2012 11:59:16 +0900 Subject: [pgsql-jp: 41046] =?iso-2022-jp?b?UG9zdGdyZVNRTCBDb25mZXJlbmNlIDIwMTIgGyRCJUEbKEI=?= =?iso-2022-jp?b?GyRCJTElQyVIO0Q/dCRvJDokKxsoQg==?= Message-ID: <20120206115916.b76b3dee.i-kaori@sraoss.co.jp> JPUG Web 会員の皆様 日本PostgreSQLユーザ会の稲葉です。 いよいよ、2/24 に迫ってまいりました、PostgreSQL Conference 2012 ですが、 事前にご購入いただく参加チケットの残数が残りわずかとなってまいりました。 昨年は数日前の完売でしたが、今年は例年を上回るペースで販売が進んでおります。 現在、カンファレンスチケット残数　25枚、レセプションチケット残数 23枚と なっております。 参加を予定しているみなさまにおかれましては、早めのチケット手配を お願い申し上げます。 なお、カンファレンスですが、急遽プログラムが追加されております。 http://www.postgresql.jp/events/pgcon2012/top また、今後もプログラム追加の予定があるため、プログラムについては、Webページを 随時チェックいただければ幸いです。 ----------------------- 日本PostgreSQLユーザ会 稲葉　香理 From xrstt070 ＠ yahoo.co.jp Thu Feb 9 15:46:45 2012 From: xrstt070 ＠ yahoo.co.jp (xrstt070 ＠ yahoo.co.jp) Date: Thu, 9 Feb 2012 15:46:45 +0900 (JST) Subject: [pgsql-jp: 41047] =?iso-2022-jp?b?UEwvcGdTUUwbJEJDZiROJWshPCVXRmIkRyROSlE/dDk5GyhC?= =?iso-2022-jp?b?GyRCPzcbKEI=?= Message-ID: <202982.36378.qm@web3403.mail.ogk.yahoo.co.jp> いつもお世話になっております。 以下のPL/pgSQLを実行した場合の動作について 質問があります。 CREATE OR REPLACE FUNCTION test() RETURNS INTEGER AS $$ DECLARE iCnt INTEGER; BEGIN FOR iCnt IN REVERSE 3 .. 1 LOOP RAISE NOTICE '%', iCnt; iCnt := 0; END LOOP; RETURN 0; END; $$ LANGUAGE 'plpgsql'; このファンクションを実行した場合、 3だけが表示され終了することを想定していましたが、 3,2,1と表示され終了しました。 これは正常な動作なのでしょうか？ CentOS、DBのバージョンは8.3.5です。 ちなみに8.2.4では3だけが表示され終了しました。 よろしくお願いします。 From xrstt070 ＠ yahoo.co.jp Fri Feb 10 18:03:42 2012 From: xrstt070 ＠ yahoo.co.jp (xrstt070 ＠ yahoo.co.jp) Date: Fri, 10 Feb 2012 18:03:42 +0900 (JST) Subject: [pgsql-jp: 41048] =?utf-8?b?UEwvcGdTUUzkuK3jga7jg6vjg7zjg5flhoXjgafjga7lpInmlbA=?= =?utf-8?b?5pu05paw?= Message-ID: <496275.76740.qm@web3402.mail.ogk.yahoo.co.jp> いつもお世話になっております。 川原と申します。 先日投稿させてもらった内容について自分なりに調べてみましたが、 8.3.0の時点から変更されてるみたいです。 ちなみに該当するプログラムはpl_exec.cのexec_stmt_fori関数のようです。 ただし、この仕様が正しいのかはまだよくわかっておりませんが。。。 リリースノートを見てみましたが、記載されていないのですかね？ 8.3のリリースノート E.1.3.11. PL/PgSQLサーバサイド言語 〓FETCHでの方向指定を含む、スクロール可能なカーソルのサポートを追加しました。(Pavel Stehule) 〓バックエンドのFETCHコマンドと合わせ、PL/PgSQLのFETCHにてFROMの代わりにINを使用可能にしました。(Pavel Stehule) 〓PL/PgSQLにMOVEを追加しました。(Magnus, Pavel Stehule, Neil) 〓RETURN QUERYを実装しました。(Pavel Stehule, Neil) 〓関数のパラメータ名を関数名で修飾できるようにしました。(Tom) 〓ブロックレベルの変数修飾が適切に動作するようにしました。(Tom) 〓FORループのSTEP値の必要条件を厳密にしました。(Tom) 〓構文エラーで報告する発生位置の精度を高めました。(Tom) From hanada ＠ metrosystems.co.jp Fri Feb 10 19:40:19 2012 From: hanada ＠ metrosystems.co.jp (=?ISO-2022-JP?B?GyRCMlZFRBsoQiAbJEJMUBsoQg==?=) Date: Fri, 10 Feb 2012 19:40:19 +0900 Subject: [pgsql-jp: 41049] Re: =?iso-2022-jp?b?UEwvcGdTUUwbJEJDZiROJWshPCVXRmIkRyROSlEbKEI=?= =?iso-2022-jp?b?GyRCP3Q5OT83GyhC?= In-Reply-To: <496275.76740.qm@web3402.mail.ogk.yahoo.co.jp> References: <496275.76740.qm@web3402.mail.ogk.yahoo.co.jp> Message-ID: <4F34F413.3010808@metrosystems.co.jp> 花田です。 (2012/02/10 18:03), xrstt070 ＠ yahoo.co.jp wrote: > 先日投稿させてもらった内容について自分なりに調べてみましたが、 > 8.3.0の時点から変更されてるみたいです。 > > ちなみに該当するプログラムはpl_exec.cのexec_stmt_fori関数のようです。 > > ただし、この仕様が正しいのかはまだよくわかっておりませんが。。。 > リリースノートを見てみましたが、記載されていないのですかね？ おそらく、8.3 のリリースノートにある ・FORループのSTEP値の必要条件を厳密にしました。(Tom) 非正のSTEP値を許しません。 また、ループのオーバーフローを取り扱いま す。 が該当する修正のようです。8.2.23 環境で提示していただいた test 関数の動 きをデバッガで追ったところ、ループ終端でのカウンタ減算で 0 から 18446744073709551615 にアンダーフローして、ループが一周で終了しました。 git のコミットでいうと 816ff27f60385d362898d8ac6523f043f888b1f5 です。 > commit 816ff27f60385d362898d8ac6523f043f888b1f5 > Author: Tom Lane > Date: Sun Jul 15 02:15:04 2007 +0000 > > Reject zero or negative BY step in plpgsql integer FOR-loops, and behave > sanely if the loop value overflows int32 on the way to the end value. > Avoid useless computation of "SELECT 1" when BY is omitted. Avoid some > type-punning between Datum and int4 that dates from the original coding. この修正により、各周回の先頭でループカウンタが本来のカウンタ値にリセット されるようになり、ループが回り始めてからカウンタを書き換えてループ回数を 制御する方法は使えなくなったようです。かなりわかりづらい挙動ですね。この 仕様ならば、いっそループカウンタは読み取り専用のほうがいい気もします。 なお、ループカウンタはループ開始時に自動的に定義されるので、DECLARE で定 義している iCnt は実際には使われていませんでした(コメントアウトしても同 じ挙動です)。 -- 株式会社メトロシステムズ 花田 茂 Mail : hanada ＠ metrosystems.co.jp Tel : 03-5951-1219 Fax : 03-5951-2929 From xrstt070 ＠ yahoo.co.jp Mon Feb 13 09:17:05 2012 From: xrstt070 ＠ yahoo.co.jp (xrstt070 ＠ yahoo.co.jp) Date: Mon, 13 Feb 2012 09:17:05 +0900 (JST) Subject: [pgsql-jp: 41050] Re: =?utf-8?b?UEwvcGdTUUzkuK3jga7jg6vjg7zjg5flhoXjgafjga7lpIk=?= =?utf-8?b?5pWw5pu05paw?= In-Reply-To: <4F34F413.3010808@metrosystems.co.jp> Message-ID: <778549.61722.qm@web3411.mail.ogk.yahoo.co.jp> 花田様 川原です。ご回答ありがとうございます。 ループカウンタについては変数を定義しなくてよかったり、 ループ内ではバージョンで挙動が違ったりと、 知らないことが多くてたいへん勉強になりました。 ありがとうございました。 --- On Fri, 2012/2/10, 花田 茂 wrote: > 花田です。 > > (2012/02/10 18:03), xrstt070 ＠ yahoo.co.jp wrote: > > 先日投稿させてもらった内容について自分なりに調べてみましたが、 > > 8.3.0の時点から変更されてるみたいです。 > > > > ちなみに該当するプログラムはpl_exec.cのexec_stmt_fori関数のようです。 > > > > ただし、この仕様が正しいのかはまだよくわかっておりませんが。。。 > > リリースノートを見てみましたが、記載されていないのですかね？ > > おそらく、8.3 のリリースノートにある > > ・FORループのSTEP値の必要条件を厳密にしました。(Tom) > 〓 〓 非正のSTEP値を許しません。 また、ループのオーバーフローを取り扱いま > 〓 〓 す。 > > が該当する修正のようです。8.2.23 環境で提示していただいた test 関数の動 > きをデバッガで追ったところ、ループ終端でのカウンタ減算で 0 から > 18446744073709551615 にアンダーフローして、ループが一周で終了しました。 > > git のコミットでいうと 816ff27f60385d362898d8ac6523f043f888b1f5 です。 > > > commit 816ff27f60385d362898d8ac6523f043f888b1f5 > > Author: Tom Lane > > Date:〓〓〓Sun Jul 15 02:15:04 2007 +0000 > > > >〓 〓〓〓Reject zero or negative BY step in plpgsql integer FOR-loops, and behave > >〓 〓〓〓sanely if the loop value overflows int32 on the way to the end value. > >〓 〓〓〓Avoid useless computation of "SELECT 1" when BY is omitted.〓 Avoid some > >〓 〓〓〓type-punning between Datum and int4 that dates from the original coding. > > この修正により、各周回の先頭でループカウンタが本来のカウンタ値にリセット > されるようになり、ループが回り始めてからカウンタを書き換えてループ回数を > 制御する方法は使えなくなったようです。かなりわかりづらい挙動ですね。この > 仕様ならば、いっそループカウンタは読み取り専用のほうがいい気もします。 > > なお、ループカウンタはループ開始時に自動的に定義されるので、DECLARE で定 > 義している iCnt は実際には使われていませんでした(コメントアウトしても同 > じ挙動です)。 > > -- > 株式会社メトロシステムズ > 〓 花田 茂 > Mail : hanada ＠ metrosystems.co.jp > Tel : 03-5951-1219 > Fax : 03-5951-2929 > From kataoka ＠ interwiz.jp Mon Feb 13 22:48:31 2012 From: kataoka ＠ interwiz.jp (Hiroki Kataoka) Date: Mon, 13 Feb 2012 22:48:31 +0900 Subject: [pgsql-jp: 41051] Re: =?iso-2022-jp?b?UEwvcGdTUUwbJEJDZiROJWshPCVXRmIkRyROSlEbKEI=?= =?iso-2022-jp?b?GyRCP3Q5OT83GyhC?= In-Reply-To: <778549.61722.qm@web3411.mail.ogk.yahoo.co.jp> References: <4F34F413.3010808@metrosystems.co.jp> <778549.61722.qm@web3411.mail.ogk.yahoo.co.jp> Message-ID: 片岡です。 2012年2月13日9:17 : > ループカウンタについては変数を定義しなくてよかったり、 これについてはマニュアルにも記載されています。 http://www.postgresql.jp/document/8.3/html/plpgsql-control-structures.html#PLPGSQL-INTEGER-FOR -- Hiroki Kataoka From anonymous ＠ smtp.sdkt.co.jp Tue Feb 14 14:57:04 2012 From: anonymous ＠ smtp.sdkt.co.jp (anonymous ＠ smtp.sdkt.co.jp) Date: Tue, 14 Feb 2012 14:57:04 +0900 Subject: [pgsql-jp: 41052] =?iso-2022-jp?b?V2luZG93cxskQkhHJE4jcCNnGyhCQWdlbnQbJEIkRxsoQkpv?= =?iso-2022-jp?b?YhskQiQsOm5ALiQ1JGwkSiQkGyhC?= Message-ID: <20120214145704.6632.D9905843@sdkt.co.jp> 皆様、お世話になります。 現在、Windows Server 2008 SE(32bit)上にて PostgreSQL 8.4.10を稼働させているのですが、 タスクスケジューラの代わりにpgAgentを使用したいと考えております。 インストールにあたっては以下の処理を行いました。 １．EnterpriseDBより、pgAgent-3.0.0-win32.zipをダウンロード。 ２．サーバのC:\Program Files\pgAdmin III\1.14配下に解凍。 　　(pgAdmin3は別途1.14.1をインストールしています) ３．pgAdmin3を起動し、自APのDB(以下、mydbとします)に対し、 　　pgagent.sqlクエリーを実行。 ４．mydbにpgagentカタログが作成されたのを確認。 ５．"C:\Program Files\pgAdmin III\1.14\pgagent.exe" INSTALL pgAgent → 　　-u postgres -p パスワード hostaddr=127.0.0.1 dbname=mydb user=postgres 　　をコマンドプロンプトで実行。 ６．サービスを起動(net start pgAgent)。 しかし、ログオンできませんと表示され(サービスを-l2オプション付きで作成)、 mydbにJobが作成されずサービスの起動に失敗します。 pghba.confは、以下の通りです。 host all all 127.0.0.1/32 md5 host mydb postgres ***.***.***.0/24 md5 ３または４の手順のいずれかで誤っていると思うのですが localhostの代わりにサーバのIP等入れてみましたが同様でした。 以上、よろしくお願いします。 From anonymous ＠ smtp.sdkt.co.jp Wed Feb 15 15:11:37 2012 From: anonymous ＠ smtp.sdkt.co.jp (anonymous ＠ smtp.sdkt.co.jp) Date: Wed, 15 Feb 2012 15:11:37 +0900 Subject: [pgsql-jp: 41053] Re: =?iso-2022-jp?b?cGdzcWwtanAgGyRCJF4kSCRhRkkkXxsoQiwgODIg?= =?iso-2022-jp?b?GyRCNCwbKEIsIDYgGyRCOWYbKEI=?= In-Reply-To: References: Message-ID: <20120215151136.F27D.D9905843@sdkt.co.jp> 自己レスです。 英文の掲示板等で同様の問題を斜め読みしていて、 StackBuilderからでもインストールできることに気づき、試したところ、 PostgreSQL 8.4.10の場合、pgAgent 3.0.1-3が設定されました。 これで見事にサービスが起動しました。 どうやら対象DBは例文通り、postgresでないとダメだったようです。 ジョブを動かすDBでないとダメなのではという思い込みがあったようです。 大変お恥ずかしい限りです。 というわけで、失礼します。 From mane24jp ＠ yahoo.co.jp Wed Feb 22 19:32:04 2012 From: mane24jp ＠ yahoo.co.jp (Mane24) Date: Wed, 22 Feb 2012 19:32:04 +0900 Subject: [pgsql-jp: 41054] =?utf-8?b?UG9zdGdyZVNRTCA5LjEuMiDjgadTcWwg44GM6YGF44GP44Gq44KL?= =?utf-8?b?44GT44Go44GM44GC44KL?= Message-ID: <4F44C424.2070405@yahoo.co.jp> お世話になります。Mame24 です。 PostgreSQL 8.4.2 Windows版（32bit）を Windows 2003 で動かしていました。 Windows 2003 では色々とタスクが動いています。 これを、 PostgreSQL 9.1.2 Windows版（32bit） にバージョンアップし、運用させて頂いています。 このアップデート後、Sqlの処理が、たまに数時間 たっても処理が終わらないものが出ていました。 ※データ件数及び、処理的にこんなに時間はかからない。 調べているうちに、wal_buffers で -1 が、以前と異なっ ていることがわかりました。 自動的に算出されることになったようなのですが、 Windows の場合、この算出はどのようになるのかがわかりません。 「PostgreSQL 9.1から、wal_buffersはデフォルトでshared_buffers の容量の1/32になり・・・。」 「windowsの場合、代わりオペレーティングシステムのキャッシュを 使用するのでshared_buffers は小さめに設定」 このように、shared_buffers は小さめにし、これに関連するものは どのように影響があるのでしょうか。 ※shared_buffers を元に算出しているパラメータが意外とある。 From maumau307 ＠ gmail.com Wed Feb 22 22:36:29 2012 From: maumau307 ＠ gmail.com (MauMau) Date: Wed, 22 Feb 2012 22:36:29 +0900 Subject: [pgsql-jp: 41055] Re: =?utf-8?b?UG9zdGdyZVNRTCA5LjEuMiDjgadTcWwg44GM6YGF44GP44Gq?= =?utf-8?b?44KL44GT44Go44GM44GC44KL?= In-Reply-To: <4F44C424.2070405@yahoo.co.jp> References: <4F44C424.2070405@yahoo.co.jp> Message-ID: <8E585E5B5F8F469B8F388EE40D13DC06@maumau> Mame24さん MauMauといいます。 wal_buffersのデフォルト値は、9.1から-1になりました。 設定値が-1の場合、WALバッファの大きさはshared_buffersの1/32になります。 ただし、実際のWALバッファの大きさは、 もしこの計算値が64KBより小さければ64KBに、 16MBより大きければ16MBに補正されます。 9.0以前ではwal_buffersのデフォルト値は64KBです。 ですので、もし8.4でもwal_buffersを設定していなかったとしたら、 WALバッファが性能劣化の原因ではないと思われます。 数時間かかるようになったSQL文は、8.4ではどのくらいの時間で終了していたのでしょうか。 何十倍もの時間がかかるのであれば、EXPLAIN ANALYZEやcontrib/auto_explainで 問合わせ計画を見てみるのがよいでしょう。 もしかすると、統計情報が正しくないために、インデックスが使われていないことも考えられます。 マニュアルの次の部分に記されているように、アップグレード後には、 ANALYZEやVACUUM ANALYZEで統計情報を収集する必要があります。 14.4.9. pg_dumpに関するいくつかの注意 http://www.postgresql.jp/document/pg910doc/html/populate.html#POPULATE-ANALYZE pg_upgrade http://www.postgresql.jp/document/pg910doc/html/pgupgrade.html 以上です。 ----- Original Message ----- From: "Mane24" To: "PostgreSQL Japanese Mailing List" Sent: Wednesday, February 22, 2012 7:32 PM Subject: [pgsql-jp: 41054] PostgreSQL 9.1.2 でSql が遅くなることがある > お世話になります。Mame24 です。 > > > PostgreSQL 8.4.2 Windows版（32bit）を > Windows 2003 で動かしていました。 > Windows 2003 では色々とタスクが動いています。 > > > これを、 > PostgreSQL 9.1.2 Windows版（32bit） > にバージョンアップし、運用させて頂いています。 > > このアップデート後、Sqlの処理が、たまに数時間 > たっても処理が終わらないものが出ていました。 > ※データ件数及び、処理的にこんなに時間はかからない。 > > 調べているうちに、wal_buffers で -1 が、以前と異なっ > ていることがわかりました。 > > 自動的に算出されることになったようなのですが、 > Windows の場合、この算出はどのようになるのかがわかりません。 > > 「PostgreSQL 9.1から、wal_buffersはデフォルトでshared_buffers > の容量の1/32になり・・・。」 > > 「windowsの場合、代わりオペレーティングシステムのキャッシュを > 使用するのでshared_buffers は小さめに設定」 > > このように、shared_buffers は小さめにし、これに関連するものは > どのように影響があるのでしょうか。 > ※shared_buffers を元に算出しているパラメータが意外とある。 From mane24jp ＠ yahoo.co.jp Thu Feb 23 12:53:51 2012 From: mane24jp ＠ yahoo.co.jp (Mane24) Date: Thu, 23 Feb 2012 12:53:51 +0900 Subject: [pgsql-jp: 41056] =?utf-8?b?IFJlOiBQb3N0Z3JlU1FMIDkuMS4yIOOBp1NxbCDjgYzpgYXjgY8=?= =?utf-8?b?44Gq44KL44GT44Go44GM44GC44KL?= In-Reply-To: <8E585E5B5F8F469B8F388EE40D13DC06@maumau> References: <4F44C424.2070405@yahoo.co.jp> <8E585E5B5F8F469B8F388EE40D13DC06@maumau> Message-ID: <4F45B84F.8090102@yahoo.co.jp> MauMau さん。ご回答ありがとう御座います。 > wal_buffersのデフォルト値は、9.1から-1になりました。 > 設定値が-1の場合、WALバッファの大きさはshared_buffersの1/32になります。 > ただし、実際のWALバッファの大きさは、 > もしこの計算値が64KBより小さければ64KBに、 > 16MBより大きければ16MBに補正されます。 > > 9.0以前ではwal_buffersのデフォルト値は64KBです。 > ですので、もし8.4でもwal_buffersを設定していなかったとしたら、 > WALバッファが性能劣化の原因ではないと思われます。 8.4 では、 shared_buffers を、64MB wal_buffers = 512kB で設定していました。 9.1 では shared_buffers を、64MB wal_buffers = -1 で、計算式より、2MB で設定されていると言うことですね。 以前より、多くのメモリが割り当てられ圧迫していたのでしょうか。 「wal_buffersの値はデフォルトでshared_buffersの容量に応じて自動的 に調整されるようになりました」 となっていたのですが、以前のバージョンのデフォルト値とずいぶん差が あるのですね。 > > 数時間かかるようになったSQL文は、8.4ではどのくらいの時間で終了していたの > でしょうか。 > 何十倍もの時間がかかるのであれば、EXPLAIN ANALYZEやcontrib/auto_explainで > 問合わせ計画を見てみるのがよいでしょう。 > もしかすると、統計情報が正しくないために、インデックスが使われていないこ > とも考えられます。 > マニュアルの次の部分に記されているように、アップグレード後には、 > ANALYZEやVACUUM ANALYZEで統計情報を収集する必要があります。 数秒程度で終了していました。 ANALYZEやVACUUM ANALYZEで統計情報を収集 は、タスクで運用開始前に行って います。 あと、autovacuum は停止してあります。 From i-kaori ＠ sraoss.co.jp Thu Feb 23 13:27:59 2012 From: i-kaori ＠ sraoss.co.jp (Kaori Inaba) Date: Thu, 23 Feb 2012 13:27:59 +0900 Subject: [pgsql-jp: 41057] =?iso-2022-jp?b?WxskQkxARnwzKzpFGyhCXVBvc3RncmVTUUwgQ29uZmVyZW5j?= =?iso-2022-jp?b?ZSAyMDEyIBskQjpHPSokTiQ0MEZGYhsoQg==?= Message-ID: <20120223132759.b8d0b698.i-kaori@sraoss.co.jp> pgsql-jp の皆様 いよいよ、PostgreSQL Conference 2012 の開催が明日となりました。 チケットを購入された方向けの最終ご案内、および、 ご参加されない方向けの Ustream 中継のご案内をさせていただきます。 =========================================================================================== PostgreSQL Conference 2012 開催日時　 2012 年 2 月 24 日（金）9:30受付開始　10:00〜17:40 主催 日本PostgreSQLユーザ会 会場 AP品川 スポンサー [ゴールド] SRA OSS, Inc. 日本支社 株式会社アシスト 　　　　　　[シルバー] 株式会社富士通ソーシアルサイエンスラボラトリ 日本ヒューレット・パッカード株式会社 VMware, Inc. [ブロンズ] 特定非営利活動法人 LPI-JAPAN 株式会社デジタル・ヒュージ・テクノロジー [メディア] DB Online 最新およびすべての情報は下記のイベントページをご確認ください。 http://www.postgresql.jp/events/pgcon2012/ 【Ustream中継について】 基調講演の中継を行います。当日参加いただけない方も是非ご覧ください。 http://www.ustream.tv/channel/pgcon12j 【コミュニケーション】 Twitter ハッシュタグ #pgcon12j を用意しています。 感想その他つぶやいていただけましたら、カンファレンススタッフも確認して対応させていただきます。 【 受付 】 おかげさまでチケットは早々に完売いたしまして、当日は 250 名程度のお客様が来場予定です。 かなりの混雑が予想されますので、受付開始の 9:30 以降、なるべくお早目の入場をお願いいたします。 なお、お買い求めいただいたローソンチケットを必ず持参ください。（お忘れの場合ご入場いただけません） また、参加者プレゼント の、「OSS-DB 標準教科書」は、先着 200 名様プレゼントとなります。 【 プログラム 】 当初のプログラムから、12:30 - 13:20 に開催される ランチセッション が 2 つ追加されています。 詳しくはプログラムを参照ください。 お弁当を持参いただけましたら、飲食しながら参加いただけますので、是非ご参加ください。 （なお、キャパシティの関係ですべてに机が用意できないため、なるべく食べやすいものをご持参ください） 【 セッション入場 】 ランチセッション以降は、会場を3つに区切り、自由に参加したいセッションに参加いただくスタイルとなります。 そのため、セッションによっては人数の偏りがでることも考えられます。 明らかにキャパシティを超える ご入場がある場合、入場を制限させていただく こともございますので、 お早目の会場移動をお願いいたします。 （各セッション終了間際での入退室はご遠慮ください） 皆様のご来場を心よりお待ちしております。 お問い合わせ PostgreSQLカンファレンス実行委員会 pgcon12j ＠ ml.postgresql.jp From maumau307 ＠ gmail.com Thu Feb 23 19:09:25 2012 From: maumau307 ＠ gmail.com (MauMau) Date: Thu, 23 Feb 2012 19:09:25 +0900 Subject: [pgsql-jp: 41058] Re: =?utf-8?b?UG9zdGdyZVNRTCA5LjEuMiDjgadTcWwg44GM6YGF44GP44Gq?= =?utf-8?b?44KL44GT44Go44GM44GC44KL?= In-Reply-To: <4F45B84F.8090102@yahoo.co.jp> References: <4F44C424.2070405@yahoo.co.jp><8E585E5B5F8F469B8F388EE40D13DC06@maumau> <4F45B84F.8090102@yahoo.co.jp> Message-ID: <545E4BF10B1C468882B662D3282C88E6@maumau> Mame24さん MauMauです。 わずか2MBのwal_buffersがメモリを圧迫したとは考えにくいです。 なぜなら、WALバッファは接続ごとに割り当てられるわけではなく、 PostgreSQLのインスタンスごとに１つ割り当てられるからです。 どのような処理に時間がかかっているかを調べるため、まずは EXPLAIN ANALYZEやcontrib/auto_explainを使うことがよいと思います。 以上です。 ----- Original Message ----- From: "Mane24" To: "PostgreSQL Japanese Mailing List" Sent: Thursday, February 23, 2012 12:53 PM Subject: [pgsql-jp: 41056] Re: PostgreSQL 9.1.2 でSql が遅くなることがある > MauMau さん。ご回答ありがとう御座います。 > >> wal_buffersのデフォルト値は、9.1から-1になりました。 >> 設定値が-1の場合、WALバッファの大きさはshared_buffersの1/32になります。 >> ただし、実際のWALバッファの大きさは、 >> もしこの計算値が64KBより小さければ64KBに、 >> 16MBより大きければ16MBに補正されます。 >> >> 9.0以前ではwal_buffersのデフォルト値は64KBです。 >> ですので、もし8.4でもwal_buffersを設定していなかったとしたら、 >> WALバッファが性能劣化の原因ではないと思われます。 > > 8.4 では、 > shared_buffers を、64MB > wal_buffers = 512kB > で設定していました。 > > 9.1 では > shared_buffers を、64MB > wal_buffers = -1 > > で、計算式より、2MB で設定されていると言うことですね。 > 以前より、多くのメモリが割り当てられ圧迫していたのでしょうか。 > > > 「wal_buffersの値はデフォルトでshared_buffersの容量に応じて自動的 > に調整されるようになりました」 > > となっていたのですが、以前のバージョンのデフォルト値とずいぶん差が > あるのですね。 > >> >> 数時間かかるようになったSQL文は、8.4ではどのくらいの時間で終了していたの >> でしょうか。 >> 何十倍もの時間がかかるのであれば、EXPLAIN ANALYZEやcontrib/auto_explainで >> 問合わせ計画を見てみるのがよいでしょう。 >> もしかすると、統計情報が正しくないために、インデックスが使われていないこ >> とも考えられます。 >> マニュアルの次の部分に記されているように、アップグレード後には、 >> ANALYZEやVACUUM ANALYZEで統計情報を収集する必要があります。 > > 数秒程度で終了していました。 > ANALYZEやVACUUM ANALYZEで統計情報を収集 は、タスクで運用開始前に行って > います。 > > あと、autovacuum は停止してあります。 > From mane24jp ＠ yahoo.co.jp Sat Feb 25 12:54:18 2012 From: mane24jp ＠ yahoo.co.jp (Mane24) Date: Sat, 25 Feb 2012 12:54:18 +0900 Subject: [pgsql-jp: 41059] Re: =?utf-8?b?UG9zdGdyZVNRTCA5LjEuMiDjgadTcWwg44GM6YGF44GP44Gq?= =?utf-8?b?44KL44GT44Go44GM44GC44KL?= In-Reply-To: <545E4BF10B1C468882B662D3282C88E6@maumau> References: <4F44C424.2070405@yahoo.co.jp><8E585E5B5F8F469B8F388EE40D13DC06@maumau> <4F45B84F.8090102@yahoo.co.jp> <545E4BF10B1C468882B662D3282C88E6@maumau> Message-ID: <4F485B6A.60603@yahoo.co.jp> MauMauさん。 Mame24です。 > わずか2MBのwal_buffersがメモリを圧迫したとは考えにくいです。 > なぜなら、WALバッファは接続ごとに割り当てられるわけではなく、 > PostgreSQLのインスタンスごとに１つ割り当てられるからです。 上記、回答ありがとう御座います。 wal_buffers ではなく現環境では原因が別にあるということを、 理解しました。 色々とありがとう御座いました。 -- > Mame24さん > > > MauMauです。 > > わずか2MBのwal_buffersがメモリを圧迫したとは考えにくいです。 > なぜなら、WALバッファは接続ごとに割り当てられるわけではなく、 > PostgreSQLのインスタンスごとに１つ割り当てられるからです。 > > どのような処理に時間がかかっているかを調べるため、まずは > EXPLAIN ANALYZEやcontrib/auto_explainを使うことがよいと思います。 > > > 以上です。 > > ----- Original Message ----- From: "Mane24" > To: "PostgreSQL Japanese Mailing List" > Sent: Thursday, February 23, 2012 12:53 PM > Subject: [pgsql-jp: 41056] Re: PostgreSQL 9.1.2 でSql が遅くなることがある > > >> MauMau さん。ご回答ありがとう御座います。 >> >>> wal_buffersのデフォルト値は、9.1から-1になりました。 >>> 設定値が-1の場合、WALバッファの大きさはshared_buffersの1/32になります。 >>> ただし、実際のWALバッファの大きさは、 >>> もしこの計算値が64KBより小さければ64KBに、 >>> 16MBより大きければ16MBに補正されます。 >>> >>> 9.0以前ではwal_buffersのデフォルト値は64KBです。 >>> ですので、もし8.4でもwal_buffersを設定していなかったとしたら、 >>> WALバッファが性能劣化の原因ではないと思われます。 >> >> 8.4 では、 >> shared_buffers を、64MB >> wal_buffers = 512kB >> で設定していました。 >> >> 9.1 では >> shared_buffers を、64MB >> wal_buffers = -1 >> >> で、計算式より、2MB で設定されていると言うことですね。 >> 以前より、多くのメモリが割り当てられ圧迫していたのでしょうか。 >> >> >> 「wal_buffersの値はデフォルトでshared_buffersの容量に応じて自動的 >> に調整されるようになりました」 >> >> となっていたのですが、以前のバージョンのデフォルト値とずいぶん差が >> あるのですね。 >> >>> >>> 数時間かかるようになったSQL文は、8.4ではどのくらいの時間で終了していたの >>> でしょうか。 >>> 何十倍もの時間がかかるのであれば、EXPLAIN ANALYZEや >>> contrib/auto_explainで >>> 問合わせ計画を見てみるのがよいでしょう。 >>> もしかすると、統計情報が正しくないために、インデックスが使われていないこ >>> とも考えられます。 >>> マニュアルの次の部分に記されているように、アップグレード後には、 >>> ANALYZEやVACUUM ANALYZEで統計情報を収集する必要があります。 >> >> 数秒程度で終了していました。 >> ANALYZEやVACUUM ANALYZEで統計情報を収集 は、タスクで運用開始前に行って >> います。 >> >> あと、autovacuum は停止してあります。 >> > >