[pgsql-jp: 28376] Re: PostgreSQLのパフォーマンス

[Tamotsu Ebina]

海老名＠インフォテックです

返信ありがとうございました。

----- Original Message ----- 
From: "Iwao Watanabe" <iwao3 ＠ DSL.gr.jp>
To: <pgsql-jp ＠ ml.postgresql.jp>
Sent: Thursday, December 19, 2002 11:44 AM
Subject: [pgsql-jp: 28374] Re: PostgreSQLのパフォーマンス


> こんにちは
> 
> 私は 今のところ PostgreSQL 7.1.x までしか利用していないので
> 下記内容はその範囲の知識で書いています。
> 間違っているなら どなたか指摘してください。
> 
> ----- Original Message ----- 
> From: "Tamotsu Ebina" <ebina ＠ pluto.dti.ne.jp>
> To: <pgsql-jp ＠ ml.postgresql.jp>
> Sent: Wednesday, December 18, 2002 5:51 PM
> Subject: [pgsql-jp: 28367] PostgreSQLのパフォーマンス
> 

> 実験されている内容は、登録されているデータの件数にもよりますが，
> 上記を1トランザクションで処理されているとすれば、それなりに重い内容ですね。
> 要件的に許されるなら１）のあとですぐにcommit したいところです。

確かに重い処理です。
１スレッドあたりの処理レコードは５００件程度、
そのうち別テーブルにインサートする対象レコードは１００件です。
再処理を行うためのプログラムを用意するのが大変なので
All or Nothing で一括してcommit or rollback しています。

> あるいは，exists を使って １）テーブルのうち、２）に含まれないものをSELECTで抽出して
> 即 ３）の別テーブルに INSERTする一発のSQLでいけそうな気もします。
> 
> 例：
> insert into foo3 ( aa,bb,cc) 
> select aa,bb,cc from foo1 
> where not exists (select * from bar2 where bar2.aa = foo1.aa)
> 
> 要件によっては
> select count(*) from foo1 
> where not exists (select * from bar2 where bar2.aa = foo1.aa)
> として まず件数を確認してから、処理を振り分けるくらい してもよいでしょう。

はい、ご指摘の通りです。
SQL言語の発想ならこうすると思いますが、手続き型言語に慣れている者が
プログラムを作成したので。

副問い合わせを使ったケースはまたテストしてみます。

> 上記の処理内容は，トランザクション遮断レベルがどれに調整されているかで
> DBMSの処理内容は思いっきり変わります。
> （もしかしたら 商用DBとPGでは 異なる遮断レベルで動作しているかもしれません。）
> 個別のトランザクションが同一のテーブルに走査と挿入を繰り返すなら
> DBMSはかなり大変な処理をしていることになります。
> 誰（それぞれのコネクションを担当するPostgresのプロセス）が
> 何時まで何を覚えておかないといけないか想像つきますか？

走査と挿入は別テーブルに対して行っています。

トランザクション遮断レベルはそれぞれのデータベースが最適と思うものに
設定されているはずだという仮定と、パフォーマンスチューニングを
個々にやりだしたら収拾がつかなくなるので、原則デフォルト値を採用して
テストを行うという方針でした。
（全てではありませんが少しの調整で大幅に効率UPが望めるものは適用しました。）

その後調べましたが、デフォルト値は
PostgreSQL　Read Committed 
商用DB　Read Committed
と両者とも同じでした。

業務的にはオンライン処理ですが、個々のスレッドから見ると
バッチ的な処理なのでRead Uncommittedでも可でした。

PGは７．３のマニュアルでもRead committed か Serializable の２つだけです。

==> 9.2. Transaction Isolation
==>  PostgreSQL offers the read committed and serializable isolation levels. 


> それから PostgreSQL の PreparedStatemen は Statement と 速度的に ちっとも変わりません。
> 毎回サーバーには展開されたSQLテキストが送られて、SQLの構文解析しているのです。

商用DBと比べCPU負荷が高い一つの理由ですね?


> 処理件数が多くて 速度が本当に要求されるのなら、
> 全部の処理をJDBCで行わないで
> 積極的にサーバーサイド言語を使うべきだと思います。
> クエリやデータをソケット経由でやり取りしないほうが 速いに決まっています。
> 上記の処理なら、１〜３ でそれが可能ですね。
> 
> これ以上は、データの性質と、実テーブルの定義と、
> 発行するつもりのSQLと  JAVAコードをみないと 
> パフォーマンス チューニングの詳しい判断は難しいような気もします。
> 

性能評価の前提が、DBサーバとアプリケーションサーバを２つおき
同一プログラムで行った場合と言う大前提があったので
JavaによりJDBCドライバを変えただけでテストしました。

個々のデータベースで最高のパフォーマンスを出すには、
一般的に通用するテクニックとデータベース固有のものがあると思いますが
移植性を考えデータベース固有のものは採用していません。

3スレッドまではPosrgreSQLの方が良い結果が出たという事は事実です。
Javaのコード中で発行しているSQL文もごく普通のもので特殊なことは
していません。

海老名＠インフォテック
--
office  ta.ebina ＠ po1.iftc.co.jp  http://www.iftc.co.jp/
private ebina ＠ pluto.dti.ne.jp  http://www.pluto.dti.ne.jp/~ebina/
[Amateur Radio Station JCG#11007 JA1QKK ] Tamotsu Ebina