5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

PostgreSQL Part.5

1 :NAME IS NULL:2007/12/01(土) 21:38:37 ID:LPSUO/OT
PostgreSQL (ぽすとぐれすきゅーえる, ぽすとぐれす) について語るスレです。
前スレ [【Windows】 PostgreSQL8 Part.1 【対応】] http://pc11.2ch.net/test/read.cgi/db/1102247223/

● 関連サイト
[PostgreSQL 本家] http://www.postgresql.org/
[日本PostgreSQLユーザ会] http://www.postgresql.jp/
[ドキュメント] http://www.postgresql.jp/document/current/html/
[ダウンロード] http://www.postgresql.jp/PostgreSQL
[pgFoundry] http://pgfoundry.org/

● 関連スレ
[2ch検索] http://find.2ch.net/index.php?STR=PostgreSQL
[WebProg/PostgreSQL 2テーブル目] http://pc11.2ch.net/test/read.cgi/php/1047317680/

2 :NAME IS NULL:2007/12/02(日) 00:41:47 ID:Q5JHapW8
>>1
乙! 盛り上がっていきましょうw

3 :NAME IS NULL:2007/12/02(日) 13:35:21 ID:???
もうpostgresSQLが入ってるサーバを全部ぶっ壊したい

4 :NAME IS NULL:2007/12/04(火) 02:25:53 ID:???
ネタがないので、PostgreSQL関連の過去ログでもはっとく。

【Windows】 PostgreSQL8 Part.1 【対応】 http://pc11.2ch.net/test/read.cgi/db/1102247223/
■   PostgreSQLのことならここで聞け   ■ http://pc8.2ch.net/test/read.cgi/db/1056960249/
■   PostgreSQLのことならここで聞け   ■ http://pc8.2ch.net/test/read.cgi/db/1091523132/
PostgresSQLについて語ろう http://pc8.2ch.net/test/read.cgi/db/1056992724/
PostgreSQLについて語ろう where OID=2::oid http://pc8.2ch.net/test/read.cgi/db/1136805513/
PostgreSQL 2テーブル目 http://pc8.2ch.net/test/read.cgi/db/1056944337/
PostgreSQL & pgsql-jp ML 3テーブル目 http://pc11.2ch.net/test/read.cgi/db/1079771059/


5 :NAME IS NULL:2007/12/04(火) 02:34:18 ID:???
「ネタがない」と書いて思い出したんだけど、8.3の正式リリースはいつかな?
年明けにでもPCを入れ替えるものがあるので、どうせなら8.3をつっこんでやろうかと思ったり。


6 :NAME IS NULL:2007/12/04(火) 09:38:05 ID:???
>>5
今月とか来月じゃなかったっけ?
セミナーでベータ版使ってくれって言ってた。

7 :NAME IS NULL:2007/12/05(水) 00:41:02 ID:gLh1+dWI
1月だね
本家のMLに流れてた

8 :5:2007/12/05(水) 00:53:45 ID:???
>>6-7
サンクス。
初夏の頃にフリーズされてから結構かかったような。
こんなもんでしたっけ? 当初夏から秋にかけてリリースする
雰囲気だったような気もするのだが。

-- 素直に8.2を入れて頃合いを見て8.3へ上げることにすっかな。


9 :NAME IS NULL:2007/12/05(水) 10:55:20 ID:???
1月リリース予定のミニプロジェクトの開発で8.3beta使ってる。
初めて使うもので (MySQL からの移行)、せっかくだから Auto VACUUM あったら楽そうでいいかなとか。

Beta 4 の文字列が公式サイトで見られるけど、配布されているもののファイル名は beta3 だね…。


10 :NAME IS NULL:2007/12/05(水) 11:05:25 ID:???
AUTO VACUUMは8.1からあるべ

11 :NAME IS NULL:2007/12/06(木) 09:01:33 ID:symOClnh
beta4やっとで配布サイトに入ったな

12 :NAME IS NULL:2007/12/07(金) 15:31:14 ID:rx0IPmKF
CentOS5でphpPgAdminをrpmでインストールしようとしています。

http://phppgadmin.sourceforge.net/?page=download
↑のページの中断にRHEL用のrpmの置き場として、
↓へのリンクがあるのですが、NotFoundになっています。
http://ftp.icdevgroup.org/phpPgAdmin/


どなたか他の置き場などご存知ないですか??


13 :NAME IS NULL:2007/12/08(土) 09:29:08 ID:???
DB使用中の一覧は以下のSQLで見られるようですが、
select * from pg_stat_activity
その接続を強制切断(強制終了)はできるのでしょうか?
Windows版使用です。

14 :NAME IS NULL:2007/12/09(日) 03:54:35 ID:Pkpabdth
>>8
9.0とメジャーバージョンアップしてもいいぐらい
機能がてんこ盛りだからね。
レビューに時間がかかったみたい。

15 :NAME IS NULL:2007/12/09(日) 04:05:49 ID:???
ポスグレと怪獣フェドラはどんどん成長してしまって、
もうわかりませんわ。

16 :NAME IS NULL:2007/12/10(月) 16:40:19 ID:???
>>13
procpid でプロセスを終了させるといいようですが、
自分自身の接続のpostgres.exe の PID(procpid)を取得する方法はあるのでしょうか?

17 :NAME IS NULL:2007/12/12(水) 08:49:31 ID:???
>>16
つpg_cancel_backend()

18 :NAME IS NULL:2007/12/13(木) 01:33:25 ID:w5o1YGhv
>>17
16が知りたいのは自分自身のPIDを取得する方法

19 :NAME IS NULL:2007/12/13(木) 12:04:20 ID:???
>>18 のレスの意味がよくわからなかったので>>17のpg_cancel_backend調べたら
引数にpidいるのかw
\df でそれらしいの探したら pg_backend_pid() というやつで返ってきたけど。

20 :NAME IS NULL:2007/12/13(木) 14:05:41 ID:???
>>17-19
ありがとうございます。

select pg_backend_pid();
で自分自身の接続のpostgres.exe の PID(procpid)を取得できますね。
http://www.fiberbit.net/user/kunyami/postgresql/statcollector/statfunc/pg_backend_pid.html

select pg_cancel_backend(引数procpid);
で"t"(trueのこと?)が返ってくるけど、プロセスがKILLされるわけじゃないようだし。。。

pg_cancel_backend(引数procpid) の使い方がよくわからないけど、ま、いっか。(^^;

21 :NAME IS NULL:2007/12/13(木) 14:11:46 ID:???
pg_cancel_backend(引数procpid)
って、たぶん実行中だとキャンセルされるっていう意味なんだろーなー?!(想像)

22 :NAME IS NULL:2007/12/13(木) 23:18:36 ID:NFig6uWq
誰かプロの方、おしえていただけませんでしょうか。

テーブルの列には、改行コード(\n)を含む文字列が格納されています。
db=# insert into testtable values('123\n456\n789');
db=# select * from testtable;
value
-------------
123
456
789

そこで、上記のように改行された状態ではなく、以下のように
改行コードが\nのままの値でデータベースに入力したいのです。。。
db=# select * from testtable;
value
---------------
123\n456\n789

このようにするには、どのようにinsertすれば良いのでしょうか。。。
すいませんが、よろしくお願いしますm(__)m

23 :NAME IS NULL:2007/12/13(木) 23:32:12 ID:???
>>22
> 改行コードが\nのままの値
改行コードが含まれているんだから、表示すると改行されるのが当たり前。

「改行コードを『'\n'という文字列に変換』して」ということなら、
INSERT INTO Table VALUES(replace('123\n456\n789','\n','\\n'));
なんかでやればいいけど、それはもう改行コードじゃなく'\n'という文字列。

24 :NAME IS NULL:2007/12/13(木) 23:33:24 ID:???
>>22
http://www.postgresql.jp/document/pg825doc/html/sql-syntax-lexical.html
の4.1.2.1.

25 :22:2007/12/14(金) 00:19:03 ID:74gC5soq
>>23
>>24
どうもありがとうございます。
ちょっと試してみます。

26 :NAME IS NULL:2007/12/14(金) 00:52:16 ID:???
>>20
pg_cancel_backend()は実行中のSQLをキャンセルする関数。
プロセスを終了させるもんではないわな。
例えば、数分間結果が返ってこないSQLを一旦キャンセルしたいようなときに使う。

27 :NAME IS NULL:2007/12/14(金) 02:15:50 ID:???
>>26
やはりそうでしたか。
どうもです。
pg_kill_pid()なんていう関数があると便利なんですがねぇ。笑

28 :NAME IS NULL:2007/12/14(金) 04:16:14 ID:???
バカって悪用される可能性を考えないんだよな。

29 :NAME IS NULL:2007/12/14(金) 05:05:24 ID:???
プロセス切られることによって、それから悪用される可能性ってあるかなぁ?

30 :NAME IS NULL:2007/12/14(金) 05:17:17 ID:???
もっとバカはね、
postgres.exe 以外のプロセスもKILLできると勘違いしてるか、
プログラミングができない人だよ。
仮にKILLできても、su や admin なら問題ない。

31 :NAME IS NULL:2007/12/14(金) 05:25:16 ID:???
次の一手は、
『釣られてるよ』
ですかね?!

32 :28:2007/12/14(金) 15:27:56 ID:???
うえへへへへ、まったくバカだぜこいつ……orz
接続毎にバックエンドが上がるのを完全に忘れてた。

危険な機能には権限で対処てのは当然思ってたけど、
pg_cancel_backend(pid)も管理者権限がないと使えないんだな。
PQcancelと違って任意のバックエンドに対して使えるみたいだから
当然だけど。

13が意図してることはさっぱり理解も同意もできないし、
単に接続終了かキャンセル+終了でよさそうなもんだけど、
調べてみるとpg_terminate_backend(pid)てのがソースにあった。
中身はSIGTERM送るだけ。
信頼性を損ねるからダメとコメントが付いてて使えないが。

長文スマソ

33 :NAME IS NULL:2007/12/14(金) 17:05:37 ID:???
プロセスの強制終了できないみたいね。
APIで強制終了できるのかな?

34 :NAME IS NULL:2007/12/14(金) 17:17:27 ID:???
>>32
>単に接続終了かキャンセル+終了でよさそうなもんだけど、

それってどういうコマンドですか?
その操作でプロセスも終了するんですか?


35 :NAME IS NULL:2007/12/14(金) 17:23:54 ID:???
32って反省文ですかね?

>>28
ちなみに悪用される危険性、わからないな。
悪用される危険性があるなら、されないように
関数を作ればいいんではないか?


36 :NAME IS NULL:2007/12/14(金) 17:28:39 ID:???
Linuxでは、該当のプロセス、KILLできますか?

37 :NAME IS NULL:2007/12/14(金) 17:58:17 ID:???
サービスの停止、最開始が手っ取り早そう。
なんの権限無しにできるのが、アレだけど。笑

悪用もへったくれもないが、さて、どんな風にからんでくるの?

38 :NAME IS NULL:2007/12/14(金) 17:59:07 ID:???
>>37
×最開始
○再開始

39 :NAME IS NULL:2007/12/14(金) 18:03:27 ID:???
>>37
Windowsの管理者権限だけが必要だね

40 :NAME IS NULL:2007/12/15(土) 08:20:17 ID:???
「今から HOGE.HOUR 時間前」 ってどう書けばいいですか?

CURRENT_TIMESTAMP - INTERVAL (HOGE.HOUR || ' hour')

と書いてみたが HOGE.HOUR で構文ネラーで撥ねられた。

41 :NAME IS NULL:2007/12/15(土) 10:02:09 ID:???
CURRENT_TIMESTAMP - CAST(HOGE.HOUR || ' hour' AS INTERVAL)
CURRENT_TIMESTAMP - (HOGE.HOUR || ' hour')::INTERVAL


42 :NAME IS NULL:2007/12/15(土) 10:10:07 ID:???
おお、でけた。
INTERVAL って前置演算子みたいなものかと思ってましたが、よく考えたら型でしたね。
ありがとうございました。

43 :NAME IS NULL:2007/12/15(土) 16:02:06 ID:???
PostgreSQL の INHERIT (テーブル定義) って中では内部結合でやってるんですか?

44 :NAME IS NULL:2007/12/15(土) 21:07:52 ID:???
Vistaに8.2.5が入らないと思ってたら、以下のページを見つけたのですが、
8.3ではインストーラの方でVista対応してくれるんでしょか?
http://www.iwahrt.com/iwahrt/ListProblemSolution.do?problemNo=185&categoryNo=13

45 :NAME IS NULL:2007/12/17(月) 08:59:44 ID:VmIYEZ1r
postgresql(linux版)を自分のノートパソコンにいれて使ってます。
某国の株価データを入れているのですが、レコードが7000万件くらいに
なってしまいます。(今はずーっとinsertしつづけていて、5000万件を
越えたところ)。まだ全部入ってないので途中なのですが、
SELECT * from stock_data;
とすると、20分ほど頑張った後でメモリ不足で表示がされませんでした。
一件のレコードは、35個のデータから構成されてます。こういう状況で
上記のSQLとかがサクサク実行できるような方法はありませんか?
メモリは2GB積んでます。
今週終わりくらいに時間がとれるので、oracleとmysqlもためしてみようと
思ってるんですが、mysqlはさわったことないし、oracleはGUI経由
で操作するのを強制されるようなところが嫌で、、psqlとかでリモートから
色々できるのがいいので、できればpostgresqlでやりたいんですが。。
あと、ティックデータも入手できれば飛躍的にデータ量が増えそうなのですが、
postgresqlの実用的な範囲って、データ量どれくらいなのでしょうか?
色々質問ばかりですいません。



46 :NAME IS NULL:2007/12/17(月) 14:00:41 ID:???
自分は詳しくないので、答えられませんが、
詳細環境も提示したほうが答えやすいかも。
少なくともPostgreSQLのバージョンは。

47 :NAME IS NULL:2007/12/17(月) 14:47:10 ID:???
DB触り始めで大量データ扱うと、最初にぶつかるよなこれ。
SELECT文で条件指定しないで全取得すれば、データ全取得しようとするから
遅いし、(クライアントの)メモリが足りなくなるよね。

とりあえずは、条件設定したり、LIMIT OFFSET で件数絞ってやってごらん。

48 :NAME IS NULL:2007/12/17(月) 14:50:17 ID:???
条件設定して件数が少なくても遅いなら、プライマリキーやインデックスがどうなってるかもチェック

49 :NAME IS NULL:2007/12/17(月) 16:18:17 ID:???
>>47
サーバではなくクライアント側のメモリが足らなくなるというのがポイントですな。
クライアント側では、普通、何万件オーダーのSQLの返りを受け取れるようにはできていないので。

50 :NAME IS NULL:2007/12/17(月) 16:19:54 ID:???
カーソルの使い方覚えて、例えば10万件ずつFETCHするような
クライアントプログラムを書けばいい。
http://www.postgresql.jp/document/current/html/sql-fetch.html
http://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor

あとは、年月毎や銘柄毎でテーブルのパーティショニングを行うとかかね。
常にデータ全体をスキャンする必要があるならあまり意味無いけど。
http://www.postgresql.jp/document/current/html/ddl-partitioning.html

51 :NAME IS NULL:2007/12/17(月) 17:00:25 ID:???
まずはcout(*)でチェクしてから、
Limit とかoffset で抽出してみるのわ?

52 :NAME IS NULL:2007/12/17(月) 17:03:15 ID:???
count(*) ですね。
これもインデックス無いとかなり時間かかると思う。

53 :NAME IS NULL:2007/12/17(月) 17:11:04 ID:???
COUNT() ってインデックス関係あるんだっけ?

54 :NAME IS NULL:2007/12/17(月) 17:54:48 ID:???
WHERE句入ってれば場合によっては

55 :50:2007/12/17(月) 18:00:28 ID:???
8.3では同期スキャンの副作用でSELECTの度に結果が変動するリスクがあるため、
ORDER BY を付けずに LIMIT, OFFSET を付けたSELECT文の実行を繰り返すと妙な事になるかもしれない。
http://journal.mycom.co.jp/special/2007/postgresql/005.html

全体のデータを取り出したいのであれば、
SELECT * FROM hoge ORDER BY idhoge LIMIT 10000 OFFSET $1; ($1には数字を入れる)
みたいなSQL文を複数回実行するより
SELECT * FROM hoge ORDER BY idhoge;
のカーソルを作ってFETCHを繰り返した方がレスポンスは良くなると思う。
(カーソルを使わないとSELECTの度にソートが行われてしまうかも?)
結果がソートされてる必要も無ければ、ORDER句も外せてさらに快適に。

56 :NAME IS NULL:2007/12/17(月) 18:15:11 ID:???
大昔に DB2 調べてて、ORDER BY + FETCH FIRST n ROWS ONLY 使うと
n 件の行を取ってきた後にソートするという動きで金玉もげるかと思ったのを思い出した。

57 :NAME IS NULL:2007/12/17(月) 22:05:56 ID:VmIYEZ1r
みなさんありがとうございます。
ようやくinsertが終了しました。
kabu=# SELECT count(*) from stock_data;
count
----------
73056656
(1 row)

主キーは、日時、会社コード1、会社コード2、の3つです。
会社コード別か、日時を範囲指定して、selectすることが多いと
思うので、それらにインデックスを設定しようかと思います。
(インデックスって勝手には設定されないですよね。)

あと、カーソルというのを調べてみます。存在すら知りませんでした。
テーブルを分けるというのは考えてみませんでしたが、上記のことを
やってみてダメだったら考えます。でもINSERTのやり直しは嫌だなあ。

それにしても、データだけでディスクをかなり占領するし、メモリ確保関係の
エラーにも何回も遭遇するし、大量データを扱うのは大変ですね。
これ以上データサイズが増えるととても扱いきれないと思いました。

あと、バージョンは、postgresql-8.2.4-27 となってました。
openSuSEのrpmのバージョンです。
ありがとうございました。

oracleとmysqlはやってみてあとで報告します。



58 :NAME IS NULL:2007/12/17(月) 22:11:07 ID:???
>>57
ノートPCでメモリ2Gでクライアント&サーバをやって
> それにしても、データだけでディスクをかなり占領するし、メモリ確保関係の
> エラーにも何回も遭遇するし、大量データを扱うのは大変ですね。
ってそりゃあ、おいおいって感じだ。

59 :NAME IS NULL:2007/12/17(月) 22:16:00 ID:???
零細がダイレクトメール用の情報扱ってるみたいな状況だな。

60 :NAME IS NULL:2007/12/17(月) 23:17:42 ID:???
7300万件w

61 :NAME IS NULL:2007/12/18(火) 09:32:43 ID:???
慣れればどうってことないけど、最初は少ない数でいろいろやったほうが
操作も覚えるしいいと思うがな

62 :NAME IS NULL:2007/12/18(火) 14:06:28 ID:???
>>57
データベースシステムを図書館と司書さんに例えると、
----------------例え話----------------------------
お客(クライアント)は、司書さんに「○○の本を貸してください(SELECT * FROM xxx WHERE ○○)」と問合せをかける。
お客は問合せの結果をバッグに入れてユーザーの所まで持ってくるわけだ。

藻前さんが最初にやったのは、図書館の本全部を一気にバッグに入れて持ってこさせようとした。そりゃ無理だ罠。

だからこそ、「○○な本のうち、50音順で500冊目から100冊持ってきて」という様に要求を区切って出したり、
「○○な本全体で、△△という単語が何回出現するか数えてきて」と集計する要求を出したりするわけだ。

DBのテーブルを分類ごとの書架だとすると、
その書架でも本がすごく多いモノ(例えば小説とか)を一定単位(作者別とか)で仕切るのをパーティショニングという。
パーティショニングされていないと、司書さんは書架全体の中から探す事になり、時間が掛かる。

インデックスっていうのは、図書館の蔵書を管理するカードの様なもので、それを元に検索すると素早く検索できる。

いくら司書さんが、本の扱いに慣れていても、一瞬一瞬に扱う本は1冊づつで、
その時扱っている本(インデックス含む)を差す指がカーソルという事だ。
----------------例え話----------------------------

株価のデータベースで、過去も含めた全てのデータを集計もせずに取り出す場面が(バックアップ目的以外で)あるとも思えない。
バックアップ用途なら、ダンプを取れば良いし、集計クエリやら条件付けやらをして、取り出す件数を絞れば、
メモリ不足でクライアントが動かなくなる事態がそうそう頻発するとは思えない。

OlacleやらMySQLにデータを移すなら、共通に使えるクライアント(ODBC等)経由で、
PostgreSQLのテーブルからSELECT INTOとか使って一気に流し込んじゃう方が楽だ。

63 :NAME IS NULL:2007/12/18(火) 23:20:02 ID:/fynqWlS
これかなーり便利だわ
http://pgfoundry.org/projects/ptop/

64 :age:2007/12/18(火) 23:53:42 ID:???
よくわからないけど、自分には関係なさそう

65 :NAME IS NULL:2007/12/19(水) 00:45:26 ID:kklpHsFG
>>63
パフォーマンスチューニングするのに使えそうね。

そういえば8.3の全文検索機能試してる人いる?

66 :NAME IS NULL:2007/12/19(水) 00:50:25 ID:???
Ludia は試して… みたい

67 :NAME IS NULL:2007/12/19(水) 10:38:38 ID:???
>>62
57じゃないが、勉強になったThx

68 :NAME IS NULL:2007/12/21(金) 03:10:15 ID:fwC7Qy9u
JPUGの忘年会は盛り上がったの?

69 :NAME IS NULL:2007/12/21(金) 10:46:56 ID:???
あー、昨日だっけ。
参加できたなー、申しこむんだった

70 :NAME IS NULL:2007/12/27(木) 00:25:14 ID:???
v8.3はまだRCも出てないんだね

71 :NAME IS NULL:2007/12/27(木) 08:24:23 ID:YLT4m45U
57です。
色々勉強になりました。(62の方とか)
ところでoracleとmysqlとの比較ですが、ノートではきついので
別のマシンでやることにしました。postgresqlへのinsertは終わったのですが、
mysqlとoracleへの移行で止まってます。

> OlacleやらMySQLにデータを移すなら、共通に使えるクライアント(ODBC等)経由で、
> PostgreSQLのテーブルからSELECT INTOとか使って一気に流し込んじゃう方が楽だ。
これについて、もう少し具体的におしえてもらえませんか?
一方のDBからselect * from tableとかでデータを読み込んで、それをselect into
で別のテーブルに流し込むんですよね?それはpsqlの中で行えますか?

上の内容が分からなかったので、postgresqlにダンプをsqlで出させて移行しようと
思ったのですが、(例えばmysqlについては、こんな感じ)
# pg_dump -d kabu > dump_file
# dump_fileを編集(テーブル一個の単純なDBなので、これは簡単そう)
# mysql -u root kabu < dump_file
これよりも速くできると思われるでしょうか?


72 :NAME IS NULL:2007/12/27(木) 10:49:45 ID:???
スクリプト書いて両方にアクセスするって話でしょ?
psqlでDOBC使わないし。
ODBC使うツールでやってくれるやつもありそうだけど。

まあ実行可能ならdumpしたSQL食わせるのでいいと思うよ

73 :NAME IS NULL:2007/12/28(金) 07:27:58 ID:???
>>71
> # pg_dump -d kabu > dump_file
> # dump_fileを編集(テーブル一個の単純なDBなので、これは簡単そう)
本当に編集が簡単と思っているのか?
7000万件INSERTした結果のdump_fileなんだぞ?
なんか最初から見てるけど、感覚がおかしい。

74 :NAME IS NULL:2007/12/28(金) 12:36:23 ID:e6yBnBlw
>>73
テーブルが一個しかなくて、編集といっても、create tableと
insert 以外を削除するだけで、7000万件のinsertには触らなかったので、、、、
スクリプト(ruby)を書いてなんとかやりました。
いまmysqlのDBにinsert中です。
insertが始まってから3時間くらいですが、もう4000万件を突破しました。
select count(*) from table;
も速いし、とりあえずmysqlのほうが速そうな感触を持ちました。

ところで7000万件がDBとして多いのかどうかいまいち見当がつかないのですが、
株価のデータとしては仕方ないというか、みんなこれくらいのサイズになって
しまうと思うのですが、大体では、
3000(上場の会社数)×340(一年で市場が開いている日数)×80(データのある年の数)=81600000
になります。(実際には昔に行くほど会社数が少なくなる)
これはやはり、多すぎると考えるべきなのでしょうか?
それともDBの使い方がまずいのでしょうか?


75 :NAME IS NULL:2007/12/28(金) 12:42:12 ID:???
>>74
少なくとも
> それともDBの使い方がまずいのでしょうか?
なんてことを書いているようなレベルの人には
> これはやはり、多すぎると考えるべきなのでしょうか?
多過ぎるかと。

76 :NAME IS NULL:2007/12/28(金) 12:48:55 ID:???
>>74
抽出条件に対して適切にINDEX張ってれば
そんなに多いって訳でもないと思うが…
>>75の言うことももっともだと思う。


77 :NAME IS NULL:2007/12/28(金) 14:39:10 ID:???
少ないデータで仕組みきっちり作ってから
大量データ流し込んでチューニング

78 :NAME IS NULL:2007/12/28(金) 21:26:08 ID:???
>>71
いまさらだろうが、クライアントPCにMS-ACCESSと各DB用のODBCドライバをインスコして、
テーブル構造だけ先に作って、
INSERT INTO コピー先 (項目1,・・・,項目n) SELECT 項目1,・・・,項目n FROM コピー元;
とかやれば、変に編集する手間もなくコピれる。

藻前さんが何をやりたいのか今ひとつ理解できないが、
MySQL、Oracle、PostgreSQLのどれを選ぶかの目安を書いてみようと思う。
・ クライアントプラットフォームが多種多様になる場合
  → ストアードプロシージャによるビジネスロジックの共通化が有効
    → OracleかPostgreSQL
・ webなどクライアントが1種類のみで処理スピードの高速化が必要な場合
  → DB単体でのスピードを優先
    → MySQL
・ DB未経験でこれから色々なシステムを構築するための勉強の場合
  → ストアードプロシージャに慣れておく事は有効
    → OracleかPostgreSQL
って感じだと思われ。

OracleとPostgreSQLだが、仕事として見た場合、
・ 客の予算が少ない or 面倒事を自分でやってでも金が欲しい時はPostgreSQL
・ 客の予算がとても多い and (客がうるさい Or 忙しいので面倒事をサポセンに任せたい)時はOracle
・ 客の予算が少ない and (客がうるさい Or 忙しいので面倒事をサポセンに任せたい)時は仕事自体をお断りする
って感じだと思われ。


79 :NAME IS NULL:2007/12/29(土) 08:56:26 ID:???
仕事自体お断りする権限がないときは辞めるしかないか・・・

80 :NAME IS NULL:2007/12/29(土) 10:08:24 ID:???
>>79
作るだけ作って辞めるのもアリだなwww
ドキュメント? メンテナンス? シラネwww

81 :NAME IS NULL:2007/12/29(土) 20:30:37 ID:???
>>79
お断り出来ないときは、見積でふっかけましょう。

メンドクサイ客で予算が少ない時は、見積次第で客をコントロールする事は可能です。
自社の営業がヘッポコな時はむずかしいですが、
自社の営業を接待漬けにするぐらいの勢いがあれば危機対応能力は向上すると思います。

82 :NAME IS NULL:2007/12/30(日) 22:50:01 ID:???
見積もりで吹っかける→「いやーそれは高いでしょう」→見積もり減

見積もりするけんg(ry

83 :NAME IS NULL:2007/12/31(月) 02:37:49 ID:???
そうですか この見積もりでだめだとしますと他をあたっていただく事になりますが。

84 :NAME IS NULL:2007/12/31(月) 13:18:59 ID:???
つ〜か、最初から予算ありきで
「お前らの見積なんぞ知らんがな。とにかくこれだけの金で作れ。」
・・・ってところも多いがな。


85 :NAME IS NULL:2007/12/31(月) 17:03:38 ID:n233Vr/g
8.3日本語版はいつでんの?

86 :NAME IS NULL:2008/01/02(水) 10:20:25 ID:???
日本語版って何よ

87 :NAME IS NULL:2008/01/02(水) 14:47:49 ID:???
すごいくだらないことかもしれなけど質問させてください。

ユーザーを管理するテーブルって何て名前にしてます?
user
はすでにあるみたいで使えないし
"user"
にすると、セレクトかける時も"user"にしなきゃならないし
tbl_user
とか接頭語や接尾語つけるのはあんまり好きじゃないし・・・
users
っていうのも考えたけど、なんでユーザーだけ複数なんだ?って感じだし

どうして、こんな一般的にみんな使いそうな名前を初期で入れてるだよ〜
他の名前にしてくれればいいのに
まあ、どうでもいいから好きなのつけろって言われそうだけど、皆さんどうしてます?

88 :NAME IS NULL:2008/01/02(水) 15:02:56 ID:???
affiliate, associate, brother, comrade, constituent, fellow, joiner, member, sister
どうでもいいから好きなのつけろ

89 :NAME IS NULL:2008/01/02(水) 17:13:26 ID:???
>>86
http://www.postgresql.jp/PostgreSQL?top

90 :NAME IS NULL:2008/01/03(木) 01:08:09 ID:???
>>89
本体は日本語版も何も無いだろう

91 :NAME IS NULL:2008/01/03(木) 16:09:34 ID:???
>>87
passwd

92 :NAME IS NULL:2008/01/03(木) 17:34:40 ID:???
>>90
そもそも本体の話しはしてない禿

93 :NAME IS NULL:2008/01/05(土) 11:36:26 ID:???
>>87
usertbl

94 :NAME IS NULL:2008/01/05(土) 12:38:26 ID:???
Oracleと性能比較した資料てどこかにある?

95 :NAME IS NULL:2008/01/05(土) 12:58:23 ID:???
>>94
そんな資料は出せないはず。Oracleが禁止してなかったっけ?
昔の話だから、今はどうか知らないけど。

96 :NAME IS NULL:2008/01/05(土) 20:22:55 ID:???
データ型として配列を使っています。
配列の要素にNULLが存在する場合にマッチするクエリは、どのように記述するのか教えてください。

PostgreSQL 8.3beta4です。

97 :NAME IS NULL:2008/01/05(土) 20:45:32 ID:Ible2iRH
http://click.j-a-net.jp/1006827/223692/


98 :NAME IS NULL:2008/01/06(日) 12:11:23 ID:???
>> 96
自前で比較用の関数用意するしかないんじゃね。
ANYとIS NULLの組み合わせじゃダメだし。

99 :NAME IS NULL:2008/01/06(日) 20:18:51 ID:???
>>98

ありがとうございます。次のテーブルに対して、
下記のクエリを作成することで対処しました。遅いですが。

create table tbl(pkey integer primary key, a integer[] not null);

select * from tbl t1 where exists(
select * from (select a,generate_series(array_lower(a,1),array_upper(a,1)) from tbl t2 where t1.pkey=t2.pkey) as t3(a,i) where a[i] is null
);


100 :NAME IS NULL:2008/01/07(月) 12:56:11 ID:???
http://itpro.nikkeibp.co.jp/members/ITPro/oss/20050722/165140/?P=2

このページのConstraint Exclusionは、条件に合う部分だけ検索がかけれるということなのでしょうか?
実際に試してみたところ、テーブル内を全て検索するのと速度があまりかわらないような気がするのですが・・・

PostgreSQL 8.2.5です

101 :NAME IS NULL:2008/01/07(月) 23:12:54 ID:???
2008-01-07 Cumulative Security Update Release (8.2.6, 8.1.11, 8.0.15, 7.4.19 and 7.3.21)
http://www.postgresql.org/about/news.905

PostgreSQL 8.3RC1 is out.
http://www.postgresql.org/ftp/source/v8.3RC1/
http://www.postgresql.org/ftp/binary/v8.3rc1/

102 :NAME IS NULL:2008/01/07(月) 23:19:12 ID:???
っと、まだ8.3rc1はアナウンスされておらず勇み足だったらしい。すまぬ。

103 :NAME IS NULL:2008/01/08(火) 08:03:14 ID:NK7MHFFt
今朝見たらアナウンスされてました。
しかし8.3は難産ですね。RCも1で終わってくれるのかな・・・?

104 :NAME IS NULL:2008/01/08(火) 08:52:18 ID:???
http://www.postgresql.org/developer/beta
http://archives.postgresql.org/pgsql-announce/2008-01/index.php

8.3rc1のアナウンスはまだじゃない?と見てたら、pgAdminIII 1.8.1 が出てるね。

pgAdmin III v1.8.1 released
http://archives.postgresql.org/pgsql-announce/2008-01/msg00001.php

105 :NAME IS NULL:2008/01/08(火) 12:50:49 ID:???
PostgreSQLに危険なセキュリティ・ホール,管理者はバージョンアップを
http://itpro.nikkeibp.co.jp/article/NEWS/20080108/290554/

106 :NAME IS NULL:2008/01/08(火) 23:54:49 ID:???
PostgreSQLに脆弱性:バージョン7.3ブランチのサポート打ち切りに
http://builder.japan.zdnet.com/news/story/0,3800079086,20364378,00.htm

PostgreSQL 7.3ブランチが終了:8.2系へアップグレードを
http://builder.japan.zdnet.com/news/story/0,3800079086,20364391,00.htm

後者の記事は、Windows版バイナリとそれ以外のEOLの話をごっちゃにしているのが何とも。

107 :NAME IS NULL:2008/01/09(水) 03:56:47 ID:???
Windows版 8.3 に期待してるのだけど
通常、PC-Unix 版に比べてどのくらい遅れてリリースされるのかな。

108 :NAME IS NULL:2008/01/09(水) 20:39:00 ID:???
>>107
普通は遅れはほぼゼロ。

109 :NAME IS NULL:2008/01/10(木) 00:13:06 ID:???
sequenceをデフォルトテーブルスペース以外に作成する方法はないんかいな?

マニュアル見ても、create/alter でテーブルスペース指定することはできないし、
serial型で自動作成されるsequenceも指定できないし。(テーブルが別テーブルスペースでもsequenceはデフォルト域になってしまう。)
最新の8.3でもだめそう。
だれかこの件について情報持ってないですか?

ちなみに、pg_classのテーブルスペース情報をupdateして、物理ファイルをmvしたら、なんとなく動いてるいるようには見える。が、さすがに本番では怖いのでやってない。


110 :NAME IS NULL:2008/01/10(木) 02:13:10 ID:???
>>108
サンクス

111 :NAME IS NULL:2008/01/10(木) 02:13:20 ID:???
>>109
そもそもSEQUENCEを別のテーブルスペースに作成する意味はあるの?
メリットが分からん。

あと、pg_classをUPDATEしなくても、移動した物理ファイルに対して、
ln でリンクを作ってやればいいんじゃない?

112 :NAME IS NULL:2008/01/10(木) 07:28:05 ID:???
>> 109
設定パラメータ default_tablespace を変更してもダメ?

>> 111
> SEQUENCEを別のテーブルスペースに作成する意味はあるの?
誰しもそう思っているから、むしろ忘れられていたのかも。
機能としてはあってもかまわない気はする。

113 :NAME IS NULL:2008/01/10(木) 21:50:07 ID:???
java+tomcatであるテーブルの列を50づつ表示するロジックを作ったとします。
まずはじめの0〜50は正常に表示されるのですが次の50を表示するを選択すると
50〜100までの表示ではなく50〜ラストまでの表示になってしますのです。
SQL文は次のようになっています"select * from -- where number > "+number+" and number <= "+number+50;
何か間違っていることがあれば指摘してください。お願いします。numberの変数はデバッグで意図した値な事を
確認しています。なおnumberはserialです。

114 :NAME IS NULL:2008/01/10(木) 21:53:18 ID:???
>>113
知らんがな。実際に発行されているSQL文を0〜50と50〜100の時で
どうなってるか確認して、psqlで実行してみなよ。

115 :NAME IS NULL:2008/01/10(木) 22:22:12 ID:???
LIMIT OFFSET のが簡単な気も

116 :NAME IS NULL:2008/01/10(木) 23:01:47 ID:???
>>113
全然関係ないけど、実験の時でも普段から PreparedStatement 使うようにしとくといいぜ。

117 :NAME IS NULL:2008/01/11(金) 00:05:06 ID:???
>>113
String + int + int って、((String + int) + int) って解釈されね?
n = 0 なら "number <= 050" で上限は 50 と解釈されるけど、
n = 50 だと "number <= 5050" になる気がするんだが。
「number <= " + (number+50)」と括弧を付ければ良いのでは。

118 :NAME IS NULL:2008/01/11(金) 00:14:40 ID:???
同じ演算子の優先順位は左から右だから >>117 の通りだよ。

int n = 50;
System.out.println("select * from ... where number > " + n + " and number <= " + n + 50);

↓結果

select * from ... where number > 50 and number <= 5050

あと Statement は事故の元だから PreparedStatement 使え。

119 :NAME IS NULL:2008/01/11(金) 00:51:40 ID:???
>>111
>>112
レスありがとうございます。

>>111
SEQUENCEを別のテーブルスペースに作成するメリットは、
テーブルを別のテーブルスペースに作成するメリットと同等と思ってます。
つまり、SEQUENCEのNextValを取得する際のI/O分散です。

>>112
default_tablespace を変更してから作成しても、だめなようです。

alter database db_hoge set defalult_tablespace = tablespace_hoge;
した上で、
crate table table_hoge( colume_hoge serial ) ;

したら、table_home は、tablespace_hoge 上に作成されますが、
colume_hoge の sequence は、oid = 0 の tablespace 上に作成されてます。


120 :113:2008/01/11(金) 09:06:04 ID:???
詳しい説明ありがとうございます。

121 :113:2008/01/11(金) 09:08:10 ID:???
が、numberはintです。

122 :NAME IS NULL:2008/01/11(金) 09:11:29 ID:???
>>121
だからさぁ、PostgreSQL的にはそんなことどーでも良いんだよ。
サーバ側で処理したSQLをチェックしろ。
意図した通りのSQLになっていて、取得結果がおかしいなら
ここで質問するのはありだが、プログラムの間違い探しなら
よそでやれ。

123 :113:2008/01/11(金) 09:29:57 ID:???
失礼しました。>117様の言う通りでした。

124 :NAME IS NULL:2008/01/11(金) 11:14:28 ID:???
"select * from -- where number > " や " and number <= " は文字列だからな。
しかしどれ使うにしても、ORDER BY つけないとな。

そして、実行するSQL文を吐き出してpsql等で確認するのは常に必須。

125 :NAME IS NULL:2008/01/11(金) 15:38:10 ID:???
あらかじめ用意されたテーブルicmpを

create table d22t11(check(time < '2005-11-22 12:00:00' and time >= '2005-11-22 11:00:00)) inherits(icmp);

というように時系列で分割した後、constraint_exclusionパラメータをonにしてSELECT文かけてみたんですが、分割前と検索速度が変わっていません・・・。
もしかして分割してからデータを挿入しなければならないのでしょうか?

126 :113:2008/01/11(金) 20:54:51 ID:???
>124 なるほど〜order by という便利なソート機能があったんですね。
更新すると列が最後尾にくるので"どうしたもんか?"と思っていたところでした。
情報ありがとうございます。

127 :NAME IS NULL:2008/01/11(金) 21:42:42 ID:???
>>119
> つまり、SEQUENCEのNextValを取得する際のI/O分散です。
それはさすがに意味ないと思う。千〜万単位で SEQUENCE 作るつもりでない限りは。
たいていはキャッシュに乗ってる。
バックアップなり信頼性目的ならば、ありうる状況かも。

128 :NAME IS NULL:2008/01/11(金) 23:34:41 ID:???
>>127
今回の疑問は、そもそも、sequenceのテーブルスペース変更はできないのは何故なのか?
という好奇心的なものが発端でして、実質的に問題が発生しているわけではありませんけどね。
対応してないなら仕方ないですね。少し残念です。

129 :NAME IS NULL:2008/01/12(土) 01:08:46 ID:???
>>125
それは、どう変わることが期待されてんの?

130 :NAME IS NULL:2008/01/12(土) 11:39:49 ID:???
>> 125
timeを検索条件にした?

131 :NAME IS NULL:2008/01/12(土) 12:31:21 ID:bIgQT3Xd
>>125

Aというテーブルが親なら、 A1 A2 A3 A4という子の
テーブルを継承で作成する。そんで、A1 A2といった子に
insert する。そうすると親のAに対してselect すると、子を見て
くれて、制約があれば関係ないのは除外するという仕組み。


132 :NAME IS NULL:2008/01/14(月) 19:14:38 ID:???
質問です。
2つのテーブル、TABLE_A と TABLE_B があります。
両者のカラム構成は同じです。
現在、使用しているテーブルは TABLE_A です。TABLE_Bは使われていません。
TABLE_B にデータ列を挿入します。
その後、両者のテーブル名を入れ替える操作を次のようなSQLで行います。

BEGIN;
ALTER TABLE "TABLE_A" RENAME TO "TABLE_TMP";
ALTER TABLE "TABLE_B" RENAME TO "TABLE_A";
ALTER TABLE "TABLE_TMP" RENAME TO "TABLE_B";
COMMIT;

このように、テーブル名をスワップする際、データ量とかによっては、
TABLE_Aにアクセスできない時間が発生するのかどうかが疑問です。
(リネーム時に何かしらデータ量に応じた処理が行われますか?)

上記テーブルデータは、WEBサービスで使うデータで、
WEB上からユーザーがアクセスしてきた際に、呼び出されます。
アクセスのタイミングによっては、ユーザーには、空データが表示されてしまうのでしょうか?

よろしくお願いします。

133 :NAME IS NULL:2008/01/15(火) 01:04:38 ID:???
>>132
> (リネーム時に何かしらデータ量に応じた処理が行われますか?)

行われない。
たぶんシステムカタログの一部が更新されるだけ。

> アクセスのタイミングによっては、ユーザーには、空データが表示されてしまうのでしょうか?

一瞬だけど TABLE_A が存在しないタイミングがあるから、
そのときのアクセスはエラーになる。

134 :NAME IS NULL:2008/01/15(火) 01:25:31 ID:???
エラーじゃなくてテーブルロックの解除待ちじゃないかな。
他からTABLE_AとTABLE_Bを順次SELECTされた場合、
タイミングによっては片方のテーブルを2度読みしちゃう可能性があるけど。

135 :133:2008/01/15(火) 02:02:36 ID:???
>>134
ALTER 文が BEGIN, COMMIT で囲まれてるの見のがしてた。
ロック待ちだね。

> 他からTABLE_AとTABLE_Bを順次SELECTされた場合、
> タイミングによっては片方のテーブルを2度読みしちゃう可能性があるけど。

1トランザクションで ALTER 文を全部実行してるから、2度読みはないはず。

136 :134:2008/01/15(火) 02:45:10 ID:???
>>135
> 1トランザクションで ALTER 文を全部実行してるから、2度読みはないはず。

TABLE_Aを読み出して、TABLE_Bも読み出そうとしたら >>132が走ってロック待ち、
解除後TABLE_Bを読み込んだら、それはリネームされる前のTABLE_A。

137 :NAME IS NULL:2008/01/15(火) 07:53:27 ID:???
>>136
最初に全部ロックを取ってしまうのはどうだろう。
BEGIN;
LOCK TABLE_A IN ACCESS EXCLUSIVE MODE;
LOCK TABLE_B IN ACCESS EXCLUSIVE MODE;
...

138 :NAME IS NULL:2008/01/15(火) 08:06:32 ID:???
ていうかそういうのは読み込み側がトランザクション分離レベルやテーブルロックを適切に設定してないだけじゃん。

139 :NAME IS NULL:2008/01/15(火) 12:57:46 ID:L9najbhe
※nextval(text)とcurrval(text)について
PHPからDBにアクセスしIDを表示するようなシステムを作っています

CREATE TABLE test_tbl (id SERIAL PRIMARY KEY,memo TEXT);
というテーブルがあり
idカラムの番号を表示で利用する場合
1)が正しい気がしますが2)でも大丈夫なきもします
1)と2)どちらがpostgres(DB)としては安全で正しい運用方法
なのか教えていただけないでしょうか?

1)IDを前もって取得し変数($id)に入れて使いまわす方法
SELECT NEXTVAL('test_tbl_id_seq');
BEGIN
INSERT INTO test_tbl(id,memo)VALUES($id,'AAAA');
COMMIT

2)IDを後から取得して使う方法
BEGIN
INSERT INTO test_tbl(memo)VALUES('AAAA');
COMMIT
SELECT CURRVAL('test_tbl_id_seq');

140 :NAME IS NULL:2008/01/15(火) 22:40:11 ID:???
>>135
ふつう、DDLにトランザクションは効かないか発行時点でcommitされてしまうと思うが。

と思って調べてみたら、SQLServerはDDLもrollbackできるんだな。


141 :NAME IS NULL:2008/01/15(火) 22:43:09 ID:???
DB2 でも普通にできるが。

142 :NAME IS NULL:2008/01/16(水) 00:22:19 ID:???
>>136
両テーブルのSELECTも、トランザクションで実行するもんだと思うが。

143 :NAME IS NULL:2008/01/16(水) 00:55:16 ID:???
>>139
どっちでも完全に一緒。お好みで。
PostgreSQLの方言でよければ RETURNING もアリ。
INSERT INTO test_tbl(memo) VALUES('AAA') RETURNING id;

144 :NAME IS NULL:2008/01/16(水) 01:13:31 ID:13aLpW9J
>>133-138
>>140-142

ご回答ありがとうございます!
大変参考になりました!

ただ、考えてみれば、
テーブルデータ更新中のアクセスに対応するための方法だったので、
更新失敗によるデータ破損や、自前の例外処理を心配するぐらいなら、
最初から1テーブルで、データ更新 (COPYで行う) 自体をトランザクションで行う方が安全だと気づきました…。
で、シーケンスを更新する、と。

ただ、空データ表示時間があったとして、その機会損失損害額を考えると
どういう方法がベストなのか今でも分かりませんが…。

ああ、SEへの道は遠いなぁ…。

皆さん、どうもありがとうございました!

145 :NAME IS NULL:2008/01/17(木) 04:44:40 ID:EaOIQdVo
Sun、MySQLを買収へ
http://www.itmedia.co.jp/enterprise/articles/0801/17/news005.html

Sun Microsystemsは、オープンソースのRDBMS「MySQL」を開発するMySQLを
総額約10億ドルで買収することを明らかにした。

 Sun Microsystemsは1月16日、オープンソースのRDBMS「MySQL」を開発する
MySQLを総額約10億ドルで買収することを明らかにした。
買収は3月末をめどに完了させる予定。MySQLはIPOを待たずして買収されることとなった。

 MySQLが自社サイトに開設しているブログに、同社のコミュニティ担当バイスプレジデント、
カイ・アーノ氏がその旨を伝えるエントリを投稿したのとほぼ同時期に、
Sunからも正式なプレスリリースが出されている。

 カイ氏はエントリの中で、「オープンソースをよく理解しているSunがMySQLを買収したことは、
MySQLコミュニティーにとっても有益なものになる」と述べている。

 一方、Sunのジョナサン・シュワルツCEOも自身のブログでこの件について言及、
MySQLの顧客に対して買収の完了を待つことなくサポートサービスの提供を開始する予定であると述べた。

 MySQLについては、過去にOracleが買収を試みたことが知られている。
今回Sunが買収したことで、OracleやMicrosoft、
IBMなどとデータベース市場で争うための基盤をSunは手に入れたことになる。

146 :NAME IS NULL:2008/01/17(木) 10:49:44 ID:???
8.3で忌まわしきVACUUMが無くなるって話を聞いたんだが、これって公式にアナウンスされてる?
もしVACUUMが無くなるならば、ようやく使えるDBになるな
速度の問題だけじゃなくて、VACUUMの手間を避けたいがゆえにMySQLに行った人って多いでしょ

147 :NAME IS NULL:2008/01/17(木) 10:53:35 ID:???
> 今回Sunが買収したことで、OracleやMicrosoft、
> IBMなどとデータベース市場で争うための基盤をSunは手に入れたことになる。

( ´д)ヒソ(´д`)ヒソ(д` )

148 :NAME IS NULL:2008/01/17(木) 12:27:46 ID:???
バキュムはどっかでやってるだけでしょ。
てか普通に空いた時間でやってくれてると思うが、
そんなに面倒かな。

149 :NAME IS NULL:2008/01/17(木) 16:25:33 ID:???
>>148
My SQL使いは Auto VACUUM の存在を知らない人が多いよ
というか、もはやPostgreSQLに目もくれないご様子で…

150 :NAME IS NULL:2008/01/17(木) 18:08:10 ID:???
なんでMySQLの話題ばかりなんだよ。
というわけで
SRA OSS、PostgreSQL 8.2をベースにしたHAクラスタソリューション
ttp://enterprise.watch.impress.co.jp/cda/software/2008/01/16/12025.html
なんて話題を振ってみる。

HAクラスタソフトにはLifeKeeperを使っているとのこと。

151 :NAME IS NULL:2008/01/17(木) 18:41:57 ID:???
>> 150

> ベースとなるPostgreSQLが8.2.5へバージョンアップ。

最近のセキュリティフィックス入ってないじゃん。

152 :NAME IS NULL:2008/01/17(木) 21:56:40 ID:???
まぁデフォルトで autovacuum が on になるから、
「設定不要になった」と言っても嘘にはならないだろう。

「VACUUMが無くなる」という発想そのものは、何も分かっていない証拠。
Oracle で UNDO セグメントを無くせないとのいっしょ。

153 :NAME IS NULL:2008/01/17(木) 22:14:51 ID:???
どうでもいいから日本postgresqlユーザ会、8.3の日本語版早く出してくれ。

154 :jin:2008/01/18(金) 11:18:11 ID:EMckNTsF
Postgre for windowsのチューニングについて教えてください。
64bit版の機器で16GBのメモリをつんだ機器でポスグレをインストール
したのですが、Shared Memoryを1GB以上にするとポスグレが起動できません。
16GBつんでるのでメモリを最大限まで使用したいです。どうしたらいいので
しょうか。教えてください。

155 :NAME IS NULL:2008/01/18(金) 15:22:21 ID:???
>>154
バージョンいくつ?バイナリは32ビット版だよね?

156 :154:2008/01/18(金) 16:10:40 ID:???
サーバー用にOS:VISTA PC買ったらPOSTGRESQLインスト出来ねえでやんの;
その時オワタおもた。

157 :NAME IS NULL:2008/01/18(金) 16:12:26 ID:???
失礼。ミスた俺は>154じゃない。

158 :NAME IS NULL:2008/01/18(金) 23:01:42 ID:???
Windows 用の 64bit バイナリってあったっけ?
少なくとも配布されているのは 32bit 版だけだったような…。
必ずしも shared_buffers にメモリを全部割り当てる必要は無いから
(OSがキャッシュに使ってくれる) 1GB で我慢しれ。

159 :NAME IS NULL:2008/01/20(日) 00:59:56 ID:???
http://japan.cnet.com/blog/hosting/2008/01/17/entry_25004180/

> 最近利用が増えてきているPostgreSQLと比較しても、約2倍ほど
> 高速に動作します。

デマが流れてるぞ

160 :NAME IS NULL:2008/01/20(日) 01:42:32 ID:rsAddFWz
>>159
だれだ さぁや って知ったかライター(インチキ)か。

posgreSQLにもMySQLにも迷惑だ。潰してやれ。

161 :NAME IS NULL:2008/01/20(日) 13:27:12 ID:???
>>160
迷惑だと言えば、MySQLスレに出張して、
やたらとSunの買収について不安を煽っている人間がいたね。
大人げ無いから止めとくれ。>>152=>>158

162 :NAME IS NULL:2008/01/20(日) 14:33:36 ID:???
ゼイタクギガサーバーがあまりにも贅沢すぎるw

163 :NAME IS NULL:2008/01/20(日) 17:00:55 ID:???
postgreSQLはMYSQLと比べて便利すぎる。

164 :NAME IS NULL:2008/01/20(日) 22:18:45 ID:???
MySQLは商用版も出てたし、業界再編の波に飲まれているのでは?

165 :NAME IS NULL:2008/01/20(日) 22:51:34 ID:???
安定して使えりゃどっちでも良いよ

166 :jin:2008/01/21(月) 09:20:39 ID:Q97Sm1d1
ver.はPostgreSQL 8.2.6です。確かに32bit版のようです。出来る限り16GB
のメモリを効率的に使用して処理速度をあげたいです。shared_buffers以外
にもどの部分のチューニングをすればいいのでしょうか。教えてください。

167 :NAME IS NULL:2008/01/21(月) 11:27:09 ID:???
アナウンスがまだだけど、PostgreSQL 8.3 RC2。
http://packages.debian.org/source/sid/postgresql-8.3

168 :初心者:2008/01/21(月) 15:28:41 ID:???
初心者です。

PostgreSQL のユーザ定義関数を使って和暦変換関数を作成したいのですが

IBMのICU4Cを使ってC++で和暦変換関数を作成しました

C++で作った和暦変換関数を組み込もうとしてるのですが、

C関数でないせいかうまくいきません。



誰か詳しい方教えてください。

169 :NAME IS NULL:2008/01/21(月) 16:48:37 ID:???
C++で作ったって、外部向け関数だけをCリンケージでやったらいいんじゃないかな。

170 :NAME IS NULL:2008/01/21(月) 16:49:42 ID:???
>>156
Vistaへのインストールはコツがいる。
ググってわからなかったらまたおいで。

171 :NAME IS NULL:2008/01/21(月) 18:42:22 ID:???
>>168
まず、どのように「うまくいかない」のか書くべし。

postgres のヘッダで、typename や delete なんかの C++ のキーワードを
仮引数名として使っている箇所があったような気がする。
postgres と繋ぐ箇所だけを別のCソースで書くか、
include 前に #define typename typename_ で誤魔化すか。

172 :初心者:2008/01/21(月) 20:49:30 ID:???
c++和暦関数
(cal_func.cpp)↓↓↓↓↓
#include <iostream>
#include <stdio.h>
#include <stdlib.h>
#include "unicode/smpdtfmt.h"
#include "japancal.h"
#include "cal_func.h"

char* cal_func(int year, int manth, int day){

/**** 略 ****/

return target;
}
(cal_func.cpp)↑↑↑↑↑



(wareki.c)↓↓↓↓↓
#include <stdio.h>
#include "postgres.h"
#include "fmgr.h"
#include "cal_func.h"

#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif

PG_FUNCTION_INFO_V1(wareki);
Datum
wareki(PG_FUNCTION_ARGS){
int32 year=PG_GETARG_INT32(0);
int32 manth=PG_GETARG_INT32(1);
int32 day=PG_GETARG_INT32(2);
char *t;
t=cal_func(year,manth,day);

text *new_t=(text *)palloc(VARSIZE(t));
VARATT_SIZEP(new_t)=VARSIZE(t);
memcpy(VARDATA(new_t),
VARDATA(t),
VARSIZE(t)-VARHDRSZ);
PG_RETURN_TEXT_P(t);
}
(wareki.c)↑↑↑↑↑


こんな感じで作ってるんですが、
どこがうまくいかないかというと
C側からcal_func()を呼び出して、C++側で西暦から和暦へ変換して
和暦に変換した文字列が返ってこないんです。

わかりにくい文章で申し訳ありませんがよろしくお願いします。

173 :NAME IS NULL:2008/01/21(月) 20:57:30 ID:???
>>172
extern "C"とかで解決する問題?

174 :NAME IS NULL:2008/01/21(月) 21:40:42 ID:???
ヘッダファイルで
#ifdef __cplusplus
extern "C" {
#endif

#include "postgres.h"
#include "fmgr.h"
char* cal_func(int year, int manth, int day);

#ifdef __cplusplus
}
#endif

ってしてるので、そこは大丈夫だと思うんですが。

一応CREATE FUNCTIONってでてるので関数は作成できてるみたいです。

たぶん問題はC++の和暦変換関数から文字列を参照渡しで渡す際にダメみたいです。


175 :NAME IS NULL:2008/01/21(月) 22:44:12 ID:17f4QTHj
ハードディスクがあふれないようにテーブルの行数に制限つけろと言われた。
100年以上運用しても余裕があるっていう資料出したのに仕様に入れてきやがった…
cronで定期的にcount取って制限に達したら古いデータを削除しようと思うんだが、
これぐらいしか方法無いよねぇ?

176 :NAME IS NULL:2008/01/21(月) 22:46:04 ID:???
>>175
トリガ使って都度チェックとか

177 :NAME IS NULL:2008/01/21(月) 22:47:59 ID:???
>>176
insertのたびにcountって重くね?

178 :NAME IS NULL:2008/01/21(月) 22:51:51 ID:???
>>177
どれくらいの行数を想定しているとか分からないから、知らんがな。
そんなこと言われても、方法を提示しただけです。

179 :NAME IS NULL:2008/01/22(火) 00:54:34 ID:???
>>175
行数より実際のディスク容量を監視した方がよくないか?
デッドタプルみたいに、行数には現れないが容量喰うものはあるわけで。

180 :NAME IS NULL:2008/01/22(火) 10:10:05 ID:tyWoTrKG
>>167
PostgreSQLの公式ページで正式にRC2が発表された模様

181 :NAME IS NULL:2008/01/22(火) 15:46:20 ID:???
そういえば、8.3ってそもそもは昨年中にリリースするつもりじゃなかったっけ?

182 :NAME IS NULL:2008/01/22(火) 17:43:02 ID:7/qXfoyh
00000_1
00000_2
11111_1

といったデータがあった場合、
group byを使って00000をまとめることはできないものでしょうか。
もしありましたらご教示いただけますと幸いです。

183 :NAME IS NULL:2008/01/22(火) 18:27:56 ID:???
GROUP BY SUBSTR(str, 0, 6) とか?

184 :NAME IS NULL:2008/01/22(火) 22:42:35 ID:???
>>179
仕様で行数って書いてあるんだから気にしない


185 :NAME IS NULL:2008/01/22(火) 23:05:16 ID:???
>>172
char *t に対して VARSIZE(t) しているのが間違い。
DirectFunctionCall1(textin) でもしておけ。

186 :NAME IS NULL:2008/01/23(水) 14:04:34 ID:???
>>175
ちょっとトリッキーな方法かもしれんけど…

・serial型の列を作成して、それを主キーにする。
・自動的に作成されるシーケンスにMAX値とCYCLEを指定する。(MAX値は最大行数)
・主キーが重複したら削除するBEFORE INSERTのトリガーを作成する。
・取り出すときはINSERT時間でも入れといて、ソートする。

187 :初心者:2008/01/23(水) 23:52:29 ID:???
>>185
何度もすみません。

どんな感じでDirectFunctionCall1(textin)を使えばいいのですか?

DirectFunctionCall1(textin,CStringGetDatum(t));

みたいな使い方でいいんですか?

教えてください。

188 :NAME IS NULL:2008/01/24(木) 08:04:47 ID:???
>>187
「DirectFunctionCall1(textin」でウェブを検索なり、Postgresのソースコードをgrepなりしてみなさい。
もし前例があれば、正しい使い方だと判断すればいい。
自分で考えるのを放棄して教えを請うのは「初心者」だからといって許されない。

189 :NAME IS NULL:2008/01/24(木) 11:20:06 ID:???
自分で調べたり考えたりググったりしない人間は、
DBやらプログラミングやらには激しく向いてない気がしてならない今日この頃

190 :NAME IS NULL:2008/01/24(木) 14:02:21 ID:???
何にも向いていない。
てかあるレベルで止まる。

191 :NAME IS NULL:2008/01/24(木) 17:17:30 ID:???
pg_dumpしようとすると
pg_dump: query to get table columns failed: ERROR: kind mismatch between backends
といったエラーが発生するのですが、pg_dumpを使わずにとりあえず
バックアップできる方法があればご教示願います。

権限は一つのDBに対して与えられているだけで、postgres権限はありません。


192 :NAME IS NULL:2008/01/24(木) 17:29:35 ID:???
>>191
pgpool使ってる?

193 :NAME IS NULL:2008/01/24(木) 17:52:08 ID:???
>>192
はい、使ってます。
色々調べてみましたところ、oid等が2台のサーバでずれている
可能性があるみたいですが、ユーザ権限では今のところどうし
ようもないという結論に至ってます。

せめて定期的にバックアップだけはとっておきたいと書き
込ませていただきました。


194 :NAME IS NULL:2008/01/25(金) 07:15:51 ID:???
pgpool経由じゃなくて、直接PostgreSQLにpg_dumpすればOK。

195 :NAME IS NULL:2008/01/25(金) 15:47:09 ID:???
>>194
アドバイス感謝です。

pgpool経由ではないようにpg_dumpすると言うことは、
各種DBサーバへ入って直接pg_dumpを行うという認識
で宜しいでしょうか。

/usr/bin/pg_dump -h 127.0.0.1 DB > backup.db

DBサーバへログインし、上記で試してみましたが、
やはりどちらからやっても同じエラーが出てしまい
ました。
大変恐れ入りますが、ご教示いただけますと幸いです。

196 :NAME IS NULL:2008/01/25(金) 16:07:47 ID:???
pgpoolへのポートじゃなくて、pgpoolが使ってるPostgreSQLへのポートを指定するのよ

197 :NAME IS NULL:2008/01/25(金) 16:11:05 ID:???
>>195
同じエラーって、それpgpoolに繋がってるんじゃ?
そのエラーメッセージはpgpoolが出してるんだけど。
違うポート番号で立ち上げてるんじゃないの?

198 :NAME IS NULL:2008/01/25(金) 19:58:28 ID:???
>>196-197

PostgreSQL指定ポートというものがわからなかったため、
とりあえず5433で以下実行しましたらいきましたので
取り急ぎご連絡させていただきます。

/usr/bin/pg_dump -h 接続IP DB -p 5433 > backup.db

本当に有難うございます。
また何かありましたら報告させていただきます。

199 :NAME IS NULL:2008/01/25(金) 23:03:32 ID:???
この辺は身体でわかってないと、無理だね。
一歩ずつね。

200 :NAME IS NULL:2008/01/27(日) 00:48:13 ID:???
便乗質問だけど、pg_poolってデフォルトでは5432
ポートで動いているんですか?
>>198は5433でPostgreSQLへ繋いでるみたいだけど。

201 :NAME IS NULL:2008/01/27(日) 00:53:29 ID:???
>>200
そりゃあ、クライアント側の設定はそのままでいけるように、pgpoolは5432でしょう。

202 :NAME IS NULL:2008/01/27(日) 10:17:02 ID:???
+1するのはセキュリチやラッパでよくあるね。
おらくるでは1522とかw

203 :NAME IS NULL:2008/01/28(月) 11:26:23 ID:SakCgkQ0
initlocationってなくなっちゃったの?

204 :NAME IS NULL:2008/01/28(月) 14:16:08 ID:qNEN3OcM
横からすみません

私はpgpoolじゃなくslony1使ってるんですが、
8.1でpg_dumpしたデータを8.2にリストアするとプロセスが落ちてしまいます。

落ちるのは毎回決まった場所で、
リストア中に「SET」という表示が出るあたりで処理が固まってしまいます。
何か心あたりある方いないでしょうか。

205 :NAME IS NULL:2008/01/28(月) 15:13:14 ID:???
漢字使ってる?

206 :204:2008/01/28(月) 15:19:51 ID:qNEN3OcM
>>205

私ですか?
使ってます。

ちなみにpg_dumpのとき文字コードは何も指定してません
-Eつけずに実行しました

207 :NAME IS NULL:2008/01/28(月) 16:07:48 ID:???
んー、Slony-Iの無い8.2に入れて、そこからまたdumpするとか。
8.2は文字コード厳しいんだよねえ、8.1と比べると。

208 :NAME IS NULL:2008/02/03(日) 01:46:04 ID:JW+WwUKE
SELECT * FROM table1 WHERE XXX...
という条件で table1 のレコードを絞り込んでいます。
このとき、この条件で絞り込んだレコードに flag=0 カラムを追加して
SELECT *, 0 AS flag FROM table1 WHERE XXX...
とし、それ以外のレコードに flag=1 カラムを追加して
SELECT *, 1 AS flag FROM table1 WHERE XXXじゃない条件...
とし、それを UNION するにはどうしたらよいでしょうか?


209 :NAME IS NULL:2008/02/03(日) 08:57:15 ID:???
>>208
UNIONだろw
UNIONじゃなくてもCASEで1,2を分けてもいいかな。

210 :NAME IS NULL:2008/02/03(日) 11:39:03 ID:???
SELECT *, CASE WHEN XXX THEN 0 ELSE 1 END AS flag FROM table1;

211 :NAME IS NULL:2008/02/04(月) 09:32:31 ID:htIE4kq7
PostgreSQL 8.3.0

212 :NAME IS NULL:2008/02/04(月) 11:05:26 ID:kJ2XdWCk
>>207
とりあえずやってみます

ただ、気になるのが2点ありまして・・・

1つ目はリストアしてるとき
「SET」ってレスポンスが出た直後に固まるところ。

2つ目はOIDが何とかってログ。
以下のログが出てるんですが・・・
-oのオプションとかいるんですかね?

server closed the connection unexpectedly
This probably means the server terminated abnormally
before or while processing the request.
connection to server was lost
LOG: server process (PID 541) was terminated by signal 11
LOG: terminating any other active server processes
LOG: all server processes terminated; reinitializing
LOG: database system was interrupted at 2008-01-23 21:41:45 JST
LOG: checkpoint record is at 0/487008
LOG: redo record is at 0/487008; undo record is at 0/0; shutdown FALSE
LOG: next transaction ID: 0/597; next OID: 24576
LOG: next MultiXactId: 1; next MultiXactOffset: 0
LOG: database system was not properly shut down; automatic recovery in progress
LOG: redo starts at 0/487058
LOG: record with zero length at 0/70F1A8
LOG: redo done at 0/70F178
LOG: database system is ready

213 :NAME IS NULL:2008/02/04(月) 15:44:34 ID:???
>>211
2008/02/01にダウンロードできるようになってるけど、
トップ更新もまだだしリリースノートもまだだねぇー。
最終チェック中?

214 :NAME IS NULL:2008/02/04(月) 20:40:02 ID:q5dGF2Ty
記念あげ


215 :NAME IS NULL:2008/02/04(月) 23:18:37 ID:???
ttp://www.postgresql.org/about/news.918

216 :NAME IS NULL:2008/02/05(火) 11:43:01 ID:???
pgAdminVでリストアするときに

pg_restore: creating PROCEDURAL LANGUAGE plpgsql
pg_restore: [archiver (db)] Error while PROCESSING TOC:
pg_restore: [archiver (db)] Error from TOC entry 283; 2612 16386 PROCEDURAL LANGUAGE plpgsql postgres
pg_restore: [archiver (db)] could not execute query: ERROR: language "plpgsql" already exists
Command was:

というエラーが出るんですけど解決方法ご存知の方いらっしゃいませんか?

エラー出てもリストアはうまくいっているようです。
ネットで調べたところ「手続き言語plpgsqlは削除しておくこと」という文言を見つけたのですが
手順がわかりません。

どうかご教授の程を。

217 :NAME IS NULL:2008/02/05(火) 17:31:00 ID:???
pgadminはバグが多いので、PostgreSQL本体の付属品ではなく、
単品の最新版をインストールすべき。それでもやっぱりある程度の
大きさのSQL流し込むとやっぱりダメなことが多いけど。

ってことで、大きなSQLを叩き込む場合は、素直にコマンドラインの
psqlを使ったほうがいい。

218 :NAME IS NULL:2008/02/05(火) 20:14:12 ID:???
8.3キターー

219 :NAME IS NULL:2008/02/05(火) 20:36:09 ID:z0f3Z9+p
すいません質問があるんですけど・・・

重複したデータを削除したいのですが記述の仕方がわかりません..
条件が非常に縛られているので削除方法がわからないんです...

このようなデータベース

○テーブル名:main1
・カラム:id, name
○テーブル名:main2
・カラム:id, info
○テーブル名:relation
・カラム:id, main1_id, main2_id, point

以上のような3つのデータベースを作りました.
relationはmain1とmain2の関連テーブルになっています.

ここで問題が起きたのですが,relationにはmain1とmain2のidを結びつけたインスタンスが
登録されています.
なのでmain1とmain2のidの組み合わせが重複することはないのですが,なぜか
存在してしまいました.
つまり,main1とmain2のidが等しいデータが違うidで存在しています.

この重複部分を削除したいのですがわからないのでカキコしました.
消すデータは後ろのidの方のデータを消したいと思っています.

このrelationのデータ数が非常に多いので,手動では時間がかかりすぎるのでSQLで解決したいんです!
どなたか教えてくれませんか??

一度,重複しているidをすべて1度selectしてからdeleteしても全然おkです.

220 :NAME IS NULL:2008/02/05(火) 20:55:50 ID:???
>>219

truncate main1;
truncate main2;
truncate relation;

でいいよ。重複部分もちゃんと削除される。



221 :NAME IS NULL:2008/02/05(火) 21:03:53 ID:gyamhWYh
TRUNCATE -- 1テーブルまたはテーブル群を空にする

ただでさえ人少ないのにさらに減らすようなことやめようよ。

222 :NAME IS NULL:2008/02/05(火) 21:32:15 ID:???
>>219 重複が合った場合は relation.id の最小のものを残す
DELETE FROM relation WHERE id NOT IN (SELECT min(id) FROM relation GROUP BY main1_id, main2_id);

もっと効率の良い方法があるかもしれない。

223 :NAME IS NULL:2008/02/05(火) 23:51:47 ID:???
>>221

重複部分「も」ちゃんと削除される
というのは正しいでしょ。やっぱりダメか(笑)

>>222 を参考にするとこんな感じでも書けるのかなぁ。
試してないけど。

create function delete_dup() returns int as $$
declare
r record;
begin
for r in select min(id) as min_id from relation
where main1_id = main2_id
group by (main1_id, main2_id)
loop
delete from relation where id <> min_id and main1_id = main2_id;
end loop;
end;
$$
language 'plpgsql';

select delete_dup();





224 :NAME IS NULL:2008/02/05(火) 23:52:26 ID:???
>>223

あ。最後に return 0; とか書いておいてね。


225 :NAME IS NULL:2008/02/06(水) 07:54:42 ID:???
>>223 むしろ遅くなるぞ。
>>222 がどういう実行プランに落ちるか、イメージできているのか?
relation へ SeqScan 1回で済むような方式でなければ、222を超えられない。

226 :NAME IS NULL:2008/02/06(水) 09:03:43 ID:???
>>225

indexがあるかどうかもわからないのに、どちらとも言えないでしょ。


227 :NAME IS NULL:2008/02/06(水) 10:19:10 ID:???
>219 8.2の初期バージョンはリストアしても完了にならないバグがあるから
何度もok選択するとデータがダブって入る。

228 :NAME IS NULL:2008/02/07(木) 00:43:43 ID:cSQE2+AL
今までAccessとSQL Serverしかさわったことがなく、
はじめてPostgreSQLを phpPgAdmin でさわっているんですが、
Accessでいうリレーションの設定は、外部キーの追加 にあたるのでしょうか?
また、リレーション図の作成といった機能、または外部ツールなど
ありましたら教えてください。
よろしくお願いします。


229 :NAME IS NULL:2008/02/07(木) 00:56:30 ID:???
リレーションはSQL文発行するときに毎回作成するんだよ
リレーション図作るならACCESSからODBCでテーブルリンクしてやっちゃった方が手っ取り早いと思う

230 :228:2008/02/07(木) 01:04:32 ID:???
さっそくのレスありがとうございます。
なるほど、そういう手がありましたか >ACCESSからODBCでテーブルリンク
リレーションについてですが、すみません、おそらく
自分が言いたかったのは、参照整合性のことだと思います。
それはやはり外部キーのことでしょうか?

231 :NAME IS NULL:2008/02/07(木) 07:36:05 ID:???
>>230
YES. 参照整合性 = 外部キー制約
http://www.techscore.com/tech/sql/03_04.html
>>229
リレーションって単にテーブルの意味で使うような。

232 :NAME IS NULL:2008/02/07(木) 12:10:58 ID:Zq40oyH1
SQLサーバーとアクセスで、年商100億以下の企業のシステムが組めるそうです。まさに、オフコンキラー・エンドユーザーキラーです。

233 :228:2008/02/07(木) 23:12:53 ID:???
>>231
ありがとうございました!
ようやく分かってきました

234 :NAME IS NULL:2008/02/08(金) 15:50:41 ID:HqMhws4W
バージョン:8.3
costとactual timeを比較しながらSQLチューニング
を行っています。

そこで質問なのですが、「costが激減したがactual timeが早くならないという」
現象は普通起きるのでしょうか?
もし起きたとすれば、それはDBサーバの処理能力が低いことが
原因と考えても宜しいでしょうか?

宜しくお願いします。

235 :NAME IS NULL:2008/02/08(金) 20:28:16 ID:???
どのDBでもそうだけど、コストっていうのは
こうしてそうしてああすればこうなるっていうのを数字にしたようなものなので
それを改善すれば必ず速くなるというものではない。

CostっていうのはSQL文の中のボトルネックを探すのに使うとよいと思う。

236 :NAME IS NULL:2008/02/09(土) 15:38:14 ID:Mdw0byD5
助けてください。

8.2.3です。

Debian上で動作しているPostgreSQLサーバの管理をすることになりました。
このDBは社内システム用に使っています。

これまでほとんど管理されてなかったサーバなので、まず色々調査しなければなりません。
しかし前任者が先日、事故で死亡してしまい、情報がありません。
ログインアカウントは現在、メモなどを探しているところなので、まだサーバに入れていません。
私はこれまで、単なるPGをしていたのでDBの管理なんて何をしたら良いのか分かりません。

まずは何をしたら良いのでしょうか?
HDDの容量見たり、topで確認したりはするつもりです。
バックアップがどうなっているかも調べるつもりです。
それと、バキュームしないとまずいよね、と聞いたので、まずはそれをするつもりですが、
他にすることはありますか?

237 :NAME IS NULL:2008/02/09(土) 15:50:23 ID:???
止める時間と別マシンがあったら、鯖からHDDすっこぬいて別のマシンにつなぎ、別マシンのルート権限で
旧マシンの/etc/passwd の周り書き換えるなり移植するなり。
つーか全部ここで言うことじゃねえや。

238 :236:2008/02/09(土) 16:03:22 ID:???
>>237
アドバイスありがとうございます。
アカウントが見つからなければその方法で試してみます。
なるべく止めたくないので、もう少し頑張ります。

239 :NAME IS NULL:2008/02/09(土) 18:49:46 ID:???
>>236
アカウントやパスワードは、
使用しているアプリケーションのソースを見たら検討つくのでは?
ログインのソースとか。
あと日次や月次などバッチ処理などが深夜などに、
別途、稼動しているかどうかも確認したほうがいいでしょう。
バキュームやバックアップもバッチで自動で行っているかもしれないでしょうし。

240 :234:2008/02/10(日) 00:32:05 ID:???
>>235
ありがとうございます。
必ず速くなるものではないんですね…勉強になりました!

241 :NAME IS NULL:2008/02/10(日) 09:35:21 ID:???
ぱっと思いつくだけでも

rootになって全ユーザのcrontabチェックしてバックアップとバキュームしてないか確認。
ついでに、バッチでDBアクセスがないか確認。(時間も控えとく)
DBの設定みてオートバキュームしてないか確認。
リモートから接続許可してる場合、許可してるマシンからもバックアップ、バキュームしてないか確認。
資料探しまくって手動cronがないか確認。(○曜日に出社したらなにかするとか)
クライアントの利用時間帯やらをヒアリング。

わかったことは全部ドキュメントに残す。


242 :236:2008/02/10(日) 14:04:58 ID:???
>>239
あ、たしかにアプリケーションのソースを見れば分りますね。
会社に行ったら確かめてみます。

>>241
手動cronは私の発想からは出てきませんでした。
ありがとうございます!

243 :NAME IS NULL:2008/02/11(月) 20:33:23 ID:???
PHPやってて
GETで持ってきた引数をデコードした文字列を問い合わせ文のWHEREの条件に入れるとうまくいかないんですがどうしてでしょうか?

アドバイスよろしくお願いします

244 :NAME IS NULL:2008/02/11(月) 20:47:25 ID:???
相手に伝える言葉の使い方が分かっていないから

245 :NAME IS NULL:2008/02/11(月) 22:26:20 ID:???
SQL文を勉強しましょう
SQL文を検証しましょう
二行ですむな

246 :NAME IS NULL:2008/02/12(火) 05:35:17 ID:???
>>243
シングルクオートの処理が間違ってるんじゃないか?

247 :NAME IS NULL:2008/02/12(火) 15:24:22 ID:???
MLのインストールの話題だけど普通は自前コンパイルなのか?
CentoOSな俺は ttp://yum.pgsqlrpms.org/howtoyum.php で入れてる


248 :NAME IS NULL:2008/02/14(木) 01:27:38 ID:???
Solarisだから普通にビルドしてるなあ
最近も64ビットでビルドするからなおさら

249 :204:2008/02/15(金) 00:03:26 ID:???
とりあえず報告を。
バージョンアップうまくいきました。
原因はSlony-Tでした。
207さんの言ってたことに近かったんでしょうか。

Slony1をアンインストールして、
その後pg_dumpallでバックアップ取る
8.2をインストールしてリストアしてから
再度Slony1をインストールとやって動かせました。

バージョンアップと冗長化一緒にやるのって
えらいめんどくさいものなんですね。。。

250 :NAME IS NULL:2008/02/15(金) 10:24:41 ID:???
BOOL型をINT型に変換するような関数はありませんか?

251 :NAME IS NULL:2008/02/15(金) 14:05:07 ID:???
どういう状況で使うか分からんが、case文でやっちゃってみてはどうか


252 :NAME IS NULL:2008/02/15(金) 20:38:59 ID:???
単にキャストすれば?
=# SELECT true::integer, false::integer;
int4 | int4
------+------
1 | 0


253 :NAME IS NULL:2008/02/18(月) 10:36:27 ID:lPcRZOP6
2回レコード全体を検索するのは無駄なので、count(*) でレコードを数えるのとレコードのデータ取得を同時にやる方法ってないでしょうか
PostgreSQLは8.2.6、PHP5.2.4から操作しています
なるべくDB側の機能を使って対処したいです

254 :NAME IS NULL:2008/02/18(月) 12:34:23 ID:???
>>253
pg_numrowsでは駄目?

255 :NAME IS NULL:2008/02/18(月) 12:53:54 ID:???
>>254
それだとoffset limitで指定した区間のレコード数しか出ないので
全件中○〜○という風に表示するために総レコード数を数えたいのです
あとPDOでやってます

256 :NAME IS NULL:2008/02/18(月) 22:28:09 ID:???
>>255

PDOだったらこれでどうよ

$offset = 0;
$limit = 10;

$sql = "SELECT * FROM hogehoge ORDER BY foobar";
$st = $conn->prepare($sql, array(PDO::ATTR_CURSOR => PDO::CURSOR_SCROLL));
$st->execute();
echo $st->rowCount() . " rows.\n"; // 件数
$i = $offset;
while($i<$offset+$limit && $row = $st->fetch(PDO::FETCH_BOTH, PDO::FETCH_ORI_ABS, $i)) {
$i++;
// 処理
}


257 :NAME IS NULL:2008/02/18(月) 22:55:50 ID:???
>>255
よくわからないけど、こんな感じとか?

select
code as コード,
hinmei as 品名,
(
select
count(code)
from syohin
) as 総数
from syohin
where
code=1

258 :NAME IS NULL:2008/02/18(月) 23:08:14 ID:???
offset と limit を使用するなら、こんな感じ?

select
code as コード,
hinmei as 品名,
(select count(code) from syohin) as 総数
from syohin
order by cocd
offset 0
limit 10

259 :NAME IS NULL:2008/02/18(月) 23:10:13 ID:???
>>258
誤字訂正
×order by cocd
○order by code

offset と limit を使用するなら、こんな感じ?

select
code as コード,
hinmei as 品名,
(select count(code) from syohin) as 総数
from syohin
order by code
offset 0
limit 10

260 :NAME IS NULL:2008/02/19(火) 11:54:27 ID:???
>>259
それでいいのですが、whereでの条件が多くなると遅くならないのですか?
検索結果をキャッシュとかしてるのだったら問題ないのですが

261 :NAME IS NULL:2008/02/19(火) 13:04:45 ID:???
>>260
心配だったら検索結果をtemporary tableにでもキャッシュしてみたら?

262 :NAME IS NULL:2008/02/20(水) 04:24:26 ID:???
>>260
詳しくないので、遅いかどうかはわかりませんが、
1つのテーブルで100万レコードからの抽出だと、
1秒ちょっとで、抽出できます。

263 :253:2008/02/20(水) 14:03:53 ID:???
気にするほどの付加増ではないようなのでサブクエリでやってみます
temporary tableとの比較もそのうちやってみたいと思います
ありがとうございました

264 :NAME IS NULL:2008/02/21(木) 06:15:23 ID:???
vacuum verbose analyzeで出力されるログをjdbcで取得する方法はありますか?
javaプログラムからvacuum実行して結果を管理画面とかで確認したいのですが。

postgres.confでinfoログも出力するように設定してログファイルを
見に行かないと駄目?

265 :NAME IS NULL:2008/02/21(木) 10:31:42 ID:???
BOOLをINTに変換する関数はありませんか?
TRUE→1
FALSE→0

MySQLではBOOL+BOOLでINT型に自動変換されますが、PgSQLでは変換されません

266 :NAME IS NULL:2008/02/21(木) 11:43:35 ID:???
>>265
>>250-252じゃいかんのか?

267 :NAME IS NULL:2008/02/21(木) 11:44:18 ID:???
case文使うか関数作る方が調べるより早いと思う。

268 :265:2008/02/21(木) 11:49:28 ID:???
うお、ちょっと前に同じような質問がっ!
ありがとうです

269 :NAME IS NULL:2008/02/21(木) 22:49:06 ID:???
> MySQLではBOOL+BOOLでINT型に自動変換
キモすぎる…

270 :NAME IS NULL:2008/02/22(金) 00:43:47 ID:???
VBとCを両方やったのでFA:LSEが0か‐1か今一得心が行くことがないのでcase文で対処

271 :NAME IS NULL:2008/02/25(月) 09:33:31 ID:???
1000万件ほどのある行から全文検索を行いたいんだけど何かお勧めない?
`tbl1` || `tbl2` || 'tbl2' … `tbl10` LIKE '%検索ワード%' とかだと、検索結果まで数秒〜数十秒まで時間がかかってしまうことがあります。

272 :NAME IS NULL:2008/02/25(月) 15:49:29 ID:???
単一テーブルでLIKE '%検索ワード%'ならもうどうしようもないんじゃないかな。
Oracle+Times10にするとか、そこだけ全部メモリに持つかしないと。

つかうちだと500万件のテーブルをselect count(1)するだけで70〜90秒くらい
かかるんだけど、1000万件でそれなら優秀なんじゃない?

ちなみにshared_buffer増やしても、検索したoidに対応するレコードがキャッシュに
あったら引っ張ってくるだけで、select countには意味ないんだよね?

273 :NAME IS NULL:2008/02/25(月) 16:40:51 ID:???
>>271
tsearch2というのがあるらしい。


274 :NAME IS NULL:2008/02/25(月) 22:18:39 ID:???
googleのアプライアンスサーバでも導入するほうがよいんでは?

275 :NAME IS NULL:2008/02/26(火) 04:10:08 ID:???
プログラムロジックを介さず、DBのみで…というのが適切な表現かどうかはわかりませんが、
PostgreSQLで、1対2とか、1対多関係のうち1対nのnを限定して表現する事は可能ですか?
また可能でしたら是非その手法をご教示頂きたいと思います。よろしくお願いします。

例えばサッカーや野球の試合は必ず2チーム間で行われますが、
試合{試合ID, 一方のチームID, 他方のチームID }
と1テーブルで冗長化した表現でなく、
試合{試合ID} <1-2> カード{試合ID, チームID}
みたく正規化した表現を使いたいのですが...
やっぱり冗長化表現が一般的なんでしょうか?

と、ここまで書いてるうちに今回必要な1-2に限定して思いついたんですが、
カードテーブルにbooleanみたいな2値のカラムを新たに設けて、そのカラムと試合IDの組を
uniqueというかPKにすればなんとかなるかなと…
booleanだとアレなのでenumにすれば、他の1-nもenumの定義によって制限できる…かな。
いやでもこれだと1-(n-m)も許容しちゃうかな…

というのはさておき、何かもっとスマートな手法があれば…何卒ご教示お願いします。

276 :NAME IS NULL:2008/02/26(火) 07:37:02 ID:???
>>275 nを厳密にしたい目的はなに?
表現の曖昧さを避けるだけなら、冗長化した形で CHECK(一方のチームID < 他方のチームID) とか。
チームIDで検索したいだけなら GIN 使う手もあるし。

277 :NAME IS NULL:2008/02/26(火) 08:35:01 ID:???
>>275
チームIDはチーム情報のマスターに格納してあるんでしょ?

278 :NAME IS NULL:2008/02/26(火) 14:54:48 ID:???
>>276
まさに、その何かの試合に関するテーブルを作ろうと思ってまして、
その際必ず試合1に対してチームが2になります。

カードを外に出したいのは、集計のためだったりします。
あるチームを基点に試合を検索する場合、一方か他方かがそのチームで、
検索されたデータからもあるチーム以外のチームを見つけなきゃいけない、
というのが面倒な気がしました。
一方外に出しておけば、おそらくクエリだけでなんとかなります。

検査制約とか配列を使うのはアリかもしれません。
ありがとうございます。


>>277
明示しませんでしたが、チームIDはチームテーブルのPKです。

279 :NAME IS NULL:2008/02/26(火) 14:57:34 ID:???
>>278
サッカーなんて単語が出てたから、PKってそっちの方かと思ってたよ。
いや、なにやらごちゃごちゃ書いてあったから詳しくは読んでないんだけどね。

280 :NAME IS NULL:2008/02/26(火) 15:32:19 ID:???
ソフトのロジックが複雑でも、
テーブル設計は、標準的でシンプルなほうがいいかもね。
メンテなどしやすい方が便利な事が多い。

281 :NAME IS NULL:2008/02/26(火) 21:47:49 ID:???
>>271
>>273
tsearch2よりはludiaの方がいいんじゃないか。
tsearch2は形態素解析。ludiaはN-gram。
形態素解析だとLIKE %% と違った結果になるぞ。

282 :NAME IS NULL:2008/02/26(火) 23:00:26 ID:???
LIKEやN-gramなら漏れが無いってわけでもないので、
割り切れるならば形態素解析も使いどころはある。適材適所で。

283 :NAME IS NULL:2008/02/26(火) 23:54:36 ID:???
WEBプログラミング板でこちらで聞いてくれと教えていただいたので質問です。

自分は初めてPostgresに触るド素人です。
Postgres8.2.5を使ってDBを作ろうとしてます。OSはLinuxです。
データベースにログイン可能なユーザーを作るため、
スーパーユーザーでCREATE ROLE name WITH PASSWORD 'pass' LOGIN;
と設定しようとしたところ『-bash: CREATE: command not found』とエラー吐かれました。
おかしいなと思ってためしにcreateuser -P nameとしたところ
『CREATE ROLE』 と出ました。
ROLE(ユーザー?)が出来たのでログインしようと試みたところ、
『su: name というユーザは存在しません』とエラーを吐かれました。
CREATE ROLEでもcreateuserでもユーザーが作れない理由と対処方がわかりません。
どなたか教えていただけないでしょうか?

284 :NAME IS NULL:2008/02/27(水) 00:33:16 ID:???
>>283
>CREATE ROLE name WITH PASSWORD 'pass' LOGIN;
これはpsql等で実行するもの。

>createuser -P name
こっちはシェル(bash等)で実行するもの。
でこっちは実行出来たっぽいね。userつってもあくまでdb用userで
psql -U name -d dbname
と言う具合につかう。

ちょっと初歩的すぎるので、何か本でも買って読んだ方がよさげ。

285 :NAME IS NULL:2008/02/27(水) 01:51:48 ID:???
>>284
丁寧な解説&ご指摘ありがとうございます。
どこで使うかをわかっていないせいで、知識がごちゃ混ぜになってたんですねorz
一からきちんと勉強しなおします。ありがとうございました。


286 :NAME IS NULL:2008/02/27(水) 15:48:47 ID:???
8.3.0 for Windowsです。

ふとログを見たら、plugin_debugger.dllというのが頻繁にロードされていました。
postgresql.confを見たら、
shared_preload_libraries = '$libdir/plugins/plugin_debugger.dll'
がデフォルトで有効になっていたんですが、このplugin_debugger.dllとは何者なんでしょうか?

287 :NAME IS NULL:2008/02/27(水) 17:03:48 ID:???
プラグインのデバッガじゃね?

288 :NAME IS NULL:2008/02/28(木) 00:26:16 ID:???
>>286 PL/pgSQL のデバッガだったはず。
使わないなら単なるリソースの無駄なので外すべし。

289 :NAME IS NULL:2008/02/28(木) 00:41:09 ID:???
plpgsqlのデバッグって出来たんだ……!

290 :NAME IS NULL:2008/02/28(木) 13:47:48 ID:???
pgpool使用時に、100回に1回くらい通常時1秒程度のplpgsqlによるストアドの返答に
数十秒、長いときだと数分かかるんですが、原因がまったく検討つきません。

アクセスは一秒数回ありますが、autovacuumの実行なども発生には関係ないようで
一度killしてから同じSQLを走らせると1秒程度で終わります。
また、ストアド実行中に同じストアドを別の引数で呼び出しても、全く問題なく実行できます。
ストアド自体にはみたところ問題はありません。
原因や解決策などに心当たりがございましたら、ご教示ください。

291 :NAME IS NULL:2008/02/28(木) 14:45:33 ID:???
自分は、詳しくないので見当つきませんが、
アドバイスを受けるのでしたら、
少なくとも、バージョンや環境は提示した方がいいでしょう。

292 :290:2008/02/28(木) 14:49:09 ID:NWie+e5y
申し訳ありません。
FreeBSD6.3、amd64
PostgreSQL8.3
pgpool-II version 2.0.1
です。

また、稼動を続けるとCPU使用率が増加していき、postgresを再起動すれば治ります。

293 :NAME IS NULL:2008/02/28(木) 15:09:55 ID:???
負荷が高くなっていくのは、運用では困りますね。
原因が見つかるといいですね。
8.2.x など旧バージョンと比較して試してみるのはどうでしょうか。

294 :NAME IS NULL:2008/02/28(木) 18:03:40 ID:???
8.3もpgpoolII 2もまだまだ枯れていないからなぁ。

295 :NAME IS NULL:2008/02/29(金) 00:52:01 ID:???
>>290
問題を切り分けるのに、PostgreSQLだけで同じ事象が
発生するか試したら?

296 :NAME IS NULL:2008/02/29(金) 13:45:44 ID:???
そうだな。pgpool切り離しと、ネットの影響もあるからlocalhostだけでやるのも

297 :NAME IS NULL:2008/02/29(金) 21:16:15 ID:sA1ohjpH
ファイアウォールとSELINUXを切ってみては?あとは
PHPとかから呼んでるなら、永続的な接続を使ってると色々
リソースを食い続けるので、非永続で。CPU使用率はpostgreSQL
が使ってるのかな? 8.3に興味あるけど、まだ怖いね。

pgpool-II Ver 2は、こういった分野のソフトにしてはバグが多い印象。
ver 1 を使ったほうがいいかもww


298 :290:2008/03/01(土) 21:56:32 ID:???
すみません、SQLを改善したら解決しました
問題きりわけのためにplpgsql内のWHERE条件を分割して実行したところ
再発しなくなりました。
元のSQLが間違ってたようには思えないのですが…

pgpoolをはずして、4BSD、ULEどちらのスケジューラーでも試しましたが
問題はpostgresql単体の問題のようです。

299 :NAME IS NULL:2008/03/01(土) 22:12:52 ID:???
時間かかった時は不適切な実行計画が選択されちゃってたとか?

300 :anonymous:2008/03/02(日) 08:06:09 ID:???
>>298
よかったですね。
旧バージョンでは問題なくても、
新バージョンで問題が発生する場合もあると思います。

301 :NAME IS NULL:2008/03/02(日) 12:58:39 ID:4NEnxdcC
>>298
参考のために、オリジナルと分割後のSQLを教えて。
もしPostgreSQLのバグなら、誰かが対処してくれるかもしれないし。

302 :920:2008/03/02(日) 22:09:11 ID:???
調査を続けていたところ、NULLが絡んだときにSQL自体が
PERFORM 1 FROM target_table
になっている場合があることに気がつきました。
これの応答に時間がかかっていたようです。
お騒がせしまして申し訳ありません。
SQL間違いとはお恥ずかしい…

303 :290:2008/03/02(日) 22:11:26 ID:???
すみません、920ではなくて290です。

304 :NAME IS NULL:2008/03/02(日) 22:22:55 ID:???
http://www.postgresql.jp/
> 重要なお知らせ:
> 2月24日にwww.postgresql.jpサーバが部外者によりクラックされていた事が判明致しました。このため、サイトは安全な別サーバに移動し、トップページのみ表示されるようになっています。
> 現在、復旧作業中です。今のところルート権限を取得された形跡は発見されていません。 詳しい情報は後日公開致します。
> ご迷惑とご心配をお掛けする事をお詫びいたします。

305 :NAME IS NULL:2008/03/03(月) 14:31:40 ID:???
うわぁ…
postgresql.jp って、SRAが事務局でサーバも提供してたのは、もう昔の話?

306 :NAME IS NULL:2008/03/04(火) 16:38:38 ID:???
うげ、8.3って数値から文字列の暗黙の型変換がされないのか。
怖すぎてアップグレードできん。

307 :NAME IS NULL:2008/03/04(火) 16:49:33 ID:???
2月27日 9:13 外部よりjpug.postgresql.jp(www.postgresql.jp)よりsshブ
        ルートフォースアタックを受けていると連絡が入る
     10:20 pscan2が走行しているのを確認し停止させる
        図らずもsshdのパスワード認証が有効になっていたため、ブ
        ルートフォースアタックで作業用アカウントのパスワードが解
        析され侵入を許していた。
        sshdのパスワード認証を禁止し、RSA認証のみとした。
     17:00 改ざん等がないか確認開始
  28日 14:00 改ざんと個人情報の流出が無いことを確認した。
3月 1日    告知用サーバ運用開始

308 :NAME IS NULL:2008/03/04(火) 22:44:35 ID:???
>>306
そんな怖くないだろ

309 :NAME IS NULL:2008/03/04(火) 23:52:04 ID:???
>>306
俺はchangelogを読まずに酷い目に遭ったぜ・・・orz

310 :NAME IS NULL:2008/03/05(水) 12:00:43 ID:???
>>308
どの言語出身かで分かれるだろうなw

311 :NAME IS NULL:2008/03/05(水) 19:44:44 ID:???
もともと date_column = 2008-03-01 っていうミスをしたという話があって、
date_column::text = (2008-03-01)::text = 2004::text
と解釈されるのはまずいとして、暗黙の型変換は削られたらしい。

ミスらないためには悪くは無いと思うけどね。
必要なら自分でキャスト追加すればいいだけだし。

312 :NAME IS NULL:2008/03/05(水) 23:06:59 ID:???
質問させてください。

pg_dumpall でデータベース全体をバックアップした後、
このデータを元に、部分的な復旧を行う事は可能ですか?

手元に pg_dumpall で取ったデータしかなくて、
それを別サーバに復元したいのですが、
全部ではなく一部分だけ復元したいです。

調べた所、丸々復元する方法は見つけたのですが、
部分的な復元方法を見つける事が出来なかったので
よろしくお願いします。

313 :NAME IS NULL:2008/03/06(木) 02:54:14 ID:???
部分的な具体例を示した方がいいと思います。

テーブル単位なのかレコード単位なのか、
カラムや部分文字列なのか。

314 :NAME IS NULL:2008/03/06(木) 03:00:03 ID:???
>>312
バックアップ時のオプションにもよるだろうけど
バックアップされたファイルは基本的にテキストファイルだから
必要な部分だけに加工してrestoreするか
一時的にどこかに全てrestoreして、必要な部分だけ
個別にpg_dumpし直すか、だね。

315 :NAME IS NULL:2008/03/06(木) 10:20:23 ID:???
なんかCLUSTER発行しても並べかえてくれない気がするんだが…
バージョンは8.2.6で

316 :NAME IS NULL:2008/03/06(木) 16:33:27 ID:???
ローカルでpgsql立てて全部入れてから改めて必要な部分を戻せばよいのでは

317 :NAME IS NULL:2008/03/06(木) 23:29:33 ID:???
質問です。

カラムの並び順を変えるには、この方法しかないのでしょうか?

テーブル Fruit = カラム名 [orange(int),apple(int),banana(int)]

BEGIN;
ALTER TABLE fruits RENAME apple TO apple_old;
ALTER TABLE fruits ADD COLUMN apple text;
UPDATE fruits SET apple = CAST(apple_old AS text);
ALTER TABLE fruits DROP COLUMN apple_old;
COMMIT;
などを複数回発行して、カラムを追加、削除により並べ替える。

MySQLには、指定したカラムとカラムの間にカラムの挿入などができたと思うのですが、
ポスグレでは、そのような機能はないのでしょうか?

よろしくお願いします。

318 :NAME IS NULL:2008/03/07(金) 00:41:47 ID:???
無いんじゃないかなあ
そういう時はテーブル丸々コピーして、新しい並びで空のテーブル作って
select insertで一括挿入っていうのをよくやるけど

319 :NAME IS NULL:2008/03/07(金) 08:09:12 ID:???
VIEW 使えば? そもそもRDBMSでカラム順に依存したSQLを書くのが間違い。

320 :NAME IS NULL:2008/03/07(金) 10:36:16 ID:???
うん、俺もVIEW使うのが正解だとオモ。
>>319の言うことは正論。

321 :NAME IS NULL:2008/03/07(金) 10:51:18 ID:???
>>317
純粋に、なぜ列の並び替えが必要になるのか知りたい。

322 :NAME IS NULL:2008/03/07(金) 11:07:36 ID:???
select * from tabの結果が気持ち悪いからじゃないの?
俺も後からカラムを追加するときに、一番最後じゃ気持ち悪いときが結構ある。

323 :NAME IS NULL:2008/03/07(金) 11:33:34 ID:???
>>322
気持ち悪いのは人だけでしょ。
プログラムを実行するコンピュータには何の関係もない。

324 :NAME IS NULL:2008/03/07(金) 14:16:29 ID:???
>>322
つか*で取るからそういうことになる。
列指定汁www

325 :NAME IS NULL:2008/03/07(金) 14:46:23 ID:???
>>323 実行する人の精神衛生状態は作業効率に直結する

326 :NAME IS NULL:2008/03/07(金) 14:48:26 ID:???
>>325
なんて言っている人の作業効率なんてたかが知れている

327 :NAME IS NULL:2008/03/07(金) 14:52:24 ID:???
すんません、vacuumに関して教えてくださいな。

vacuum -a -f -zは毎日夜中に一度やるとして・・・

・オンライン中にvacuumしていいのですか?
(極端に遅くなるとか、壊れる等はありますか?って意味が一番強い)
・いいのであれば、vacuumのオプションは何が最適かしら?

土日は更新メイン。平日は参照メインなシステムです。
バージョンは、8.2.6です。
よろしくお願いします。

328 :NAME IS NULL:2008/03/07(金) 14:57:09 ID:???
MyISAM の ORDER BY 無しのデフォルトの並び順での取り出しは、
確かに挿入順であって結構速い気がする。
この動作に依存して組む人たちもいるんじゃないだろうか。

329 :NAME IS NULL:2008/03/07(金) 15:02:16 ID:???
>>328
それ行の話でしょ? いま問題になっているのは列の並び

330 :NAME IS NULL:2008/03/07(金) 18:19:48 ID:???
vacuumは遅くなるから夜中にやってるなら
それで良いと思うけど。

うちは随時更新、参照入るシステムだけど、
処理重い時間にvacuumやると結構やばい。

vacuum1回で足りないと感じるのは何故だろう?
メモリが十分にあるならチューニングしたらどう?
ttp://www.thinkit.co.jp/free/marugoto/2/1/11/

autovacuumはどうなのか知らん

331 :NAME IS NULL:2008/03/07(金) 19:56:07 ID:???
世の中にはソースのないプログラムとかもあるからなぁ。
データベースの列の並びがちがうだけで動かなくなる糞プログラムなんかに限ってソースが無かったりする。
俺は今またそれに引っかかったよ。   orz

332 :NAME IS NULL:2008/03/07(金) 23:47:46 ID:???
そんなプログラムにこそ、カラムの挿入なんてやったらダメなんでは。

333 :NAME IS NULL:2008/03/08(土) 09:12:47 ID:???
>>327
vacuum -a -z だけで十分。
VACUUM FULL は必要ないよ。

オンライン中の VACUUM で DB が壊れることはないし、
極端に遅くなることもないけど、負荷が気になるなら
vacuum_cost_delay とか VACUUM のコストを弄ってやればいい。

334 :NAME IS NULL:2008/03/09(日) 01:19:17 ID:???
create table hoge( foo integer not null );
create table fuga( bar integer not null check( bar < foo ) ) inherits( hoge );

こんな感じに継承元と先とでの数値の検査制約って出来ないんだっけ?

335 :NAME IS NULL:2008/03/10(月) 23:45:35 ID:???
>>334 まったく問題なくできるようだが。

336 :327:2008/03/11(火) 14:16:00 ID:???
>>330,333
ありがとう。

>vacuum1回で足りないと感じるのは何故だろう?
うーん、一個件数の多いテーブル(100万件ぐらい)があって、
そこが土日の更新の対象で且つ、結構他のテーブルとjoinしてるんですよ。
一応、explainで見て、indexの見直しと対象SQLのチューニングをして、
大分早くなったんだけど、1年で100万件程度増えるので、
いつかはまた遅くなるんだろうと感じてます。
なので、手軽?に早くする手法はないかと調べていた訳です。

オンラインのVACUUMで壊れないのであれば、
一度負荷と相談して試して見ます。
ありがとさんでした。

ところで、V8.x系のメモリチューニングで、1GB以上共有メモリを取っても、
メモリマネージメントの都合で逆に遅くなるってあるんだけど、
やっぱりそういう物なんですかね?
サーバー4GBにしたのに無駄?

337 :NAME IS NULL:2008/03/12(水) 00:35:41 ID:???
>>336
パーティショニングすれば?

> サーバー4GBにしたのに無駄?
共有メモリ以外はOSキャッシュとして使われるから、
まったく無駄にならん。

338 :NAME IS NULL:2008/03/12(水) 19:51:58 ID:???
>>337
レスありがとう。

パーティショニングを今度試してみるダス。
日々の売り上げデータに近い構造なので、
効果は大きそうな気がします。
大抵の集計自体も長くて3ヶ月ぐらいだし。

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

339 :NAME IS NULL:2008/03/13(木) 00:47:20 ID:???
共有メモリ1G以上だと遅くなるのってどっかに書いてある?



340 :NAME IS NULL:2008/03/13(木) 08:07:54 ID:???
> 共有メモリ1G以上だと遅くなる
というよりは、単に増やせば増やすほど速くなるわけではないってこと。
DB/OS 2層でキャッシュするよう設計されているから。
他のデータベースでも似たようなことはよくある。

341 :NAME IS NULL:2008/03/13(木) 19:38:18 ID:RTgKtkUI
>>339

8.1のチューニングのページに書いてあった気がします。自分の8.1
での経験ですが、20Gとか指定すると、小さなテーブルのdrop table すら
1秒くらいかかった記憶が、、、。


>>338

おなじく8.1での話ですが、パーティショニングしたテーブルをjoinす
ると、selectがシーケンシャルになって激遅になるケースがありました。
同じ構造で同じSQLでも8.3はインデックスを使ってくれるんですけどね


342 :NAME IS NULL:2008/03/13(木) 20:43:28 ID:???
>>341 たしかに drop table は遅くなるかも。メモリ全部舐めるから。
drop table を高速化する目的でチューニングすべきかは疑問だが。

343 :NAME IS NULL:2008/03/14(金) 00:29:37 ID:???
temp tableしまくるなら効果ありそうだなw


344 :NAME IS NULL:2008/03/14(金) 01:03:30 ID:???
>>341
> 20Gとか指定すると、

実メモリはいくら積んでたの?

345 :NAME IS NULL:2008/03/14(金) 01:19:18 ID:???
>>343 temp table はローカルバッファなので関係なかったりする。

346 :NAME IS NULL:2008/03/14(金) 09:25:11 ID:???
>>339
http://itpro.nikkeibp.co.jp/members/ITPro/oss/20050402/158372/?P=2

ここ以外にも、具体的な数値を上げて書いてあったところが
あったと思うけど、おもいだせませんでした。

347 :NAME IS NULL:2008/03/14(金) 23:16:26 ID:gKUPvhD2
drop table だけじゃなくて、delete して insert する処理も、もっさり感が
ありました。0コンマ何秒の処理だったけど、共有メモリ1.5G設定時の
2倍くらいの所要時間だったイメージ。DB全体のサイズは6G程度です。

>>344

会社のサーバなので、たしか30G台でした。


348 :NAME IS NULL:2008/03/15(土) 07:58:18 ID:???
>>347 そんな豪勢な環境はめずらしいからなぁ。
共有メモリ20GBなんて大きな設定は、テストが足りてないのかも。
4GBを超えるとちょっと心配だな。
あまらせてもOSがキャッシュとして使うから、無駄にはならないし。

349 :NAME IS NULL:2008/03/16(日) 01:45:48 ID:???
>>313>>314>>316
亀レスすいません。
>>316の方法で行く事にします。
どうもありがとうございます。

350 :NAME IS NULL:2008/03/17(月) 21:50:44 ID:???
数百万件以上など、どんどん増えていくテーブルに対して遅くなっていく場合の対処ですが、
日付で管理できるテーブルなら、
例えば、
今月とそれ以前のテーブルに分割してみるとかは?
バッチでレコードの移行を行う必要が出たり、
プログラムの変更が必要になりますが。

その場合、veiwで対応ということが考えられますが、
例えば、レコードが少ないテーブルAとレコードが多いテーブルBの連結を記述しているveiwの場合、
テーブルAにINSERTなど変更が加わる際、
veiwのレコードが多いテーブルBの影響を受けて、多少遅くなるということはあるのでしょうか?
あったとしても、気になる程度じゃないのかな?


351 :NAME IS NULL:2008/03/17(月) 21:53:17 ID:???
veiw

352 :NAME IS NULL:2008/03/17(月) 22:03:59 ID:???
失礼。よく間違えるんですよ。(^^;

353 :NAME IS NULL:2008/03/17(月) 22:18:35 ID:???
>>350
千万件ぐらいならclusterかければ直ぐに結果返ってくるよ
一億件は試した事ないから判らんw

354 :NAME IS NULL:2008/03/17(月) 22:30:52 ID:???
>>353
ありがとうございます。
やったことはないので、試してみます。

現在、Group by など複数のSQLを一度に発行しているので、
それが完了するのに、20〜30秒くらいかかっています。
さらに早くなるとストレスなくなるなぁ。


355 :NAME IS NULL:2008/03/17(月) 22:32:28 ID:???
view って、select など、参照する時だけにしか使用されずってことで、
insert や update には、全く影響はないのかな?

356 :NAME IS NULL:2008/03/17(月) 22:34:53 ID:???
あ、view って、insert 時など、キーの重複などの整合性をチェックしてたっけ?(^^;
なんか、そんなことがあったような。。。

357 :NAME IS NULL:2008/03/18(火) 18:30:33 ID:cmzwaPqX
pgpool3.2のバグで、FreeBSD4.11上でmakeできないらしいので
3.1.2を入れようと思うのですがどこかでげとできますか?
bugfixした3.4.1をmakeることも考えたのですが、稼動中のサーバに
突っ込むので開発版は避けたいところです。

358 :NAME IS NULL:2008/03/18(火) 19:18:39 ID:1so+byeI
8.3.1 & 8.2.7

359 :NAME IS NULL:2008/03/19(水) 04:27:00 ID:???
>>350
適切なindexを介してアクセスする場合は対数オーダーだから、それが可能ならば
1テーブルで済ませる方が絶対有利。
どうしてもfull scanが必要となる処理ではテーブル分割も考えられるが、
union viewを使う場合、ちゃんとプランナがそれを認識してあらかじめ不要な
テーブルを実行計画から除外することが出来ないとかえって遅くなる。

360 :NAME IS NULL:2008/03/19(水) 08:04:05 ID:???
>>359
削除のことも考えた方がいい。
テーブルを分割する最大のメリットは、古いデータの一括削除だから。
絶対に削除しないならば、確かに分割する利点は薄い。

361 :NAME IS NULL:2008/03/21(金) 02:39:37 ID:bZgunjjY
www.postgresql.jp 繋がらない(´・ω・`)

362 :NAME IS NULL:2008/03/21(金) 02:53:43 ID:???
>>361
未確認情報だけど、またクラックされたから復旧中らしいよ。

363 :NAME IS NULL:2008/03/21(金) 05:06:01 ID:???
>>362
その話がMLに流れたって、スラドのアレたまで見たよ。

364 :NAME IS NULL:2008/03/21(金) 16:07:05 ID:???
>>359-360

どうも。
1テーブルだと、どんどん増えて数百万レコード件以上になり、
1画面の表示に20〜40秒はかかってしまいます。
分割すると、数千レコードなので、1〜2秒以内で終わります。
将来は数千万レコードにもなり、もっとかかってしまいます。

ひとつのSQLで済むまない10以上のSQLの処理を行っている情報てんこ盛り画面なので。。。

365 :NAME IS NULL:2008/03/21(金) 20:59:17 ID:3PY9kdIC
>>364

数千レコードで1〜2秒の処理って、、、どんなSQLなんでしょう?
処理範囲分のデータを一時テーブルに取り出して使えば、それで
速くなったりはしないですか?


366 :NAME IS NULL:2008/03/22(土) 15:18:52 ID:???
>>364
正規化されていないってオチじゃないよね?
複雑なデータ取得でカーソルすら使ってないとかだったら
単純に技量不足だと思うよ

367 :NAME IS NULL:2008/03/23(日) 01:51:18 ID:???
>>365-366
どうもありがとうございます。

>>365
合計で1〜2秒ですから、
ひとつのSQLで、0.1秒〜0.2秒以下ということですが、それでも遅いですかね?
ほとんど全部が、Group by 使用のSQLです。

一時テーブルへ抽出ですか。
普通のテーブルへInsertでしょうか?
その方法はメモリなど特殊な方法でしょうか?
一時テーブルへ抽出しても、複数同時アクセスが頻繁にあるので、
同じテーブル利用にならないよう個別利用になるよう考慮する必要があります。
同じテーブル利用で重複しても数万レコードですから、
Delete & Insert が早ければ、効果あるかもしれません。
しかし、頻繁に画面更新を行うので、Insertが多くなり、意味があるかどうか。
頻繁にバキュームしないといけなくなるのかな?

>>366
カーソルは使っていません。
カーソル利用とSQLでどのくらいの差があるのか知りませんが、
10倍以上と劇的に早くなるようでしたら、今後検討してみますが、
はっきり言って、管理と工数のことを考えると面倒ですね。
ただ、カーソル制御はわかりますが、
SQLをどう、カーソル使用で置き換えて利用するのか、勉強不足で、わかりません。

正規化とは、どの意味で、言われているかわかりませんが、
PostgreSQL固有で言われるものでしたら、正規化はしていません。
もちろん、冗長データはありません。

368 :NAME IS NULL:2008/03/23(日) 03:00:03 ID:???
>>365-366
次に、ひとつのSQLを紹介します。(改行が多いので)
テーブル名やカラム名は、変えていますが、
生のSQLです。
まだ未熟なので、SQL自体を見直す点もあるとは思います。
テーブル詳細を紹介できないので、わかりづらいと思いますが、
table001が100万レコード以上で、
約、1.2秒〜2.0秒かかります。
数千レコードでしたら、
0.2秒前後です。

このようなSQLが1画面に10以上あると合計、20〜40秒以上になってしまうので、
よく使う該当レコードをテーブルを分割して数千レコードにすると、合計1〜2秒で収まります。
テーブル設計自体やインデックスの見直し、チューニング次第でまだ高速になるのは間違いないと思いますが、
将来的に、数百万、数千万レコード以上になる前提では、
テーブル分割で1〜2秒の現在と同様に早くなるとは思えないので、検討もしていない現状です。


369 :NAME IS NULL:2008/03/23(日) 03:01:30 ID:???
(改行が多いので続き)
------------------------
select
case
when ee.kbn001='' then ''
when ee.kbn001='1' then '区分1'
when ee.kbn001='2' then '区分2'
when ee.kbn001='3' then '区分3'
when ee.kbn001='4' then '区分4'
when ee.kbn001='5' then '区分5'
else null
end as kbn001,
case
when ee.kbn001='2' then ee.kbn002
else 'kbn002'
end as kbn002,
aa.name as 名称,
aa.kana as カナ,
aa.tel,
case
when cc.flg001=1 then 'フラグ1'
when cc.flg001=2 then 'フラグ2'
when cc.flg001=3 then 'フラグ3'
when cc.flg001=4 then 'フラグ4'
when cc.flg001=5 then 'フラグ5'
else null
end as flg001,
case
when aa.kbn003='0' then '区分30'
when aa.kbn003='1' then '区分31'
when aa.kbn003='2' then '区分32'
else null
end as kbn003,
'' as dummy,
dd.sum_kei as 計,
translate(aa.biko,'
',' ') as 備考,
bb.jun as 順番,
bb.code01 as コード


370 :NAME IS NULL:2008/03/23(日) 03:02:06 ID:???
(改行が多いので続き)
------------------------
from
(
select
min(jun) as jun,
code01
from table001
where
code002 =6
and translate(to_date(data001,'yyyy/mm/dd'),'-','/')='2008/03/21'
group by
code01
) bb
left join data002 aa
on (aa.code01=bb.code01
)
left join data003 cc
on aa.code01=cc.code01 and cc.code002 =6
and translate(to_date(cc.data001,'yyyy/mm/dd'),'-','/')='2008/03/21'
left join
(
select
code01,
coalesce(sum(kingaku001),0) + coalesce(sum(kingaku002),0) as sum_kingaku001
from table001 aaa
where
aaa.code002 =6
and translate(to_date(aaa.data001,'yyyy/mm/dd'),'-','/')='2008/03/21'
group by
code01
) dd
on aa.code01=dd.code01
left join table003 ee
on (aa.code01=ee.code01 and ee.code002=6)
order by bb.jun
------------------------


371 :NAME IS NULL:2008/03/23(日) 08:41:01 ID:???
>>369-370
これじゃ遅いだろうね。
code002のカーディナリティが低くてdata001に関数インデックスも
設定していないなら、そのクエリは table001 の seq scan が発生
するというのはわかるかな?
検討する気もないんだったらどうでもいいが。

372 :NAME IS NULL:2008/03/23(日) 09:38:31 ID:???
> translate(to_date(data001,'yyyy/mm/dd'),'-','/')='2008/03/21'
「関数(列) = 定数」の書き方ではインデックスが使われない。
data001列をdate型に置き換えて date001 = '2008/03/21' か、
timestamp型なら '2008/03/21' <= date001 AND date001 < '2008/03/22' にするか。

一般的な方針としては、文字列型を減らす(意味にあう他の型を使う)のが良い。

373 :NAME IS NULL:2008/03/23(日) 10:16:54 ID:YDmnE8vH
>>367

一時テーブルですが、

create template(?) table *** as select * from table001 where ***

とかで、必要な範囲のtable001のデータを持った一時テーブルをメモリ上に
つくれます。他の接続とは干渉しないので、複数処理とかは気にせず
でOK。delete も必要ないです。pgpoolとか使ってるなら、使用後に dropが必要。
んで、一時テーブルを使って処理すれば、とりあえず簡単に速く
なると思うけど



374 :NAME IS NULL:2008/03/23(日) 11:35:59 ID:???
>>371-372
ありがとうございます。
文字列だと遅くなるのは、認識していますが、
「関数(列) = 定数」だと、インデックスが使用されませんか。
考えてみると、そうですよね。致命的欠陥ですね。
date001 = '2008/03/21'
の書き方にすると、4倍ほど早くなり、1.2秒が、0.3秒ほどになりました。
まずは、データの統一整備をして、
translate(to_date(data001,'yyyy/mm/dd'),'-','/')='2008/03/21'の記述をやめ、
date001 = '2008/03/21'の記述にしようと思います。
データ型の変更は、時期を見て検討しようと思います。

>>373
ありがとうございます。
簡単にメモリ上にできるのでしたら、時期をみて試してみようと思います。
pgpoolは使用していません。今のところも予定はありません。

375 :NAME IS NULL:2008/03/23(日) 13:50:33 ID:???
>>374 の補記
>致命的欠陥ですね。

は、私の設計、SQLが欠陥という意味です。念のため。

376 :NAME IS NULL:2008/03/24(月) 12:50:57 ID:???
>>375
大丈夫。その意味が分かる人間ならクエリを見た時点で分かっていると思うぞ。
まあ何だ。頑張れ。

377 :NAME IS NULL:2008/03/26(水) 20:53:54 ID:HwJR8fjT
LEFT JOINでの結合に関する質問です。

頭の中でごちゃごちゃやる分には、
結合の順番によって内部処理のコストが大分変わりそうですが、
PostgreSQLの実際の作業としては、
SQL最適化した上で実行されるから関係ないのでしょうか?

(実際はもっと複雑ですが)
例えば以下のようなSQLでtable_a、table_b共に数百万件あったとします。
数百万件を結合した上で、table_bで絞り込むより、
table_bで絞り込んだ後にtable_aを結合した方がコストがかからないような場合です。

SELECT *
FROM table_a
LEFT JOIN table_b
WHERE
table_b.id=1;

378 :NAME IS NULL:2008/03/26(水) 21:07:32 ID:???
>>377

explain してみるといいのでは。

379 :NAME IS NULL:2008/03/27(木) 10:42:10 ID:???
360万件のテーブルAをselect count(1) するのに
85秒もかかっていて悩んでいます。別の730万件のテーブルBは11秒でした。
テーブルAデータ量は1GBは超えていると思います。テーブルBは数十MBくらい。

環境:
OS:Linux(FC7)
PostgreSQL8.3
Core Duo@2.66GHz
Mem:4GB (認識は3.6GB)
設定
shared_buffer 1500MB
work_mem 256MB

shared_bufferは大きくしすぎても遅くなるとかの情報があったのですが、
なんか速くする設定とかありますか?


380 :377:2008/03/27(木) 16:11:25 ID:tPBRhLWv
>>378
explainの結果をどう見たらよいのか良く分からなかったのです(DB毎に違い過ぎますよね)。
検索していたらよさげな情報を見つけたので、explainしてみます。ありがとうございます。
SQLiteやMySQLのexplainよりも実用的なようですね。

>>379
primary key をはっていないのでは??

381 :NAME IS NULL:2008/03/27(木) 22:12:57 ID:???
>>379
単にテーブルサイズが大きくて、ディスク読み込みが大量に発生しているからでは?
キャッシュに乗った後の速度で良ければ、synchronize_seqscans = off を試してみると良いかも。
他に、更新を繰り返したせいでテーブルが太っているならば、
いったんCLUSTERなりVACUUM FULLなりをかけてみるとか。

>>380
何の効果も無いぞ > primary key

382 :NAME IS NULL:2008/03/27(木) 23:54:21 ID:???
すいません8.2.5でした
>>381
synchronize_seqscans = offは試してみます。と思ったけど8.3からなのかな。
ディスク読込のせいなのはほぼまちがい無いんだけど、shared_buffers割り当てを
増やしてもほとんど解決しなかった。もしかしてpostgresのキャッシュって、
queryでoidを読み出して、そのoidに対応するデータがキャッシュされてれば
キャッシュを見るだけなんじゃないのかなあと思ったんだけど、それで合ってる?
そう考えるとメモリはOSのディスクキャッシュに回した方がいいんじゃないかなとも
思ったんだけど。

vacuum fullは一回途中までかけたんだけど、20分くらい返ってこないのでやめた。
365d24hサービス中なので厳しい。vacuum analyzeは毎日かけるようにしたけど。



383 :NAME IS NULL:2008/03/28(金) 01:14:47 ID:???
365日24時間稼動しているなら、
まずは、テストできる予備機は必要ですね。

あとはサーバーの再起動とか。。。
365日24時間稼動で、それも不可能ならメンテ期間しか無理ということになりますね。

384 :NAME IS NULL:2008/03/28(金) 08:18:06 ID:???
>>382
ぜんぜんちゃう。oidなど使わない。

テーブルBの「数十MBに11秒」でもものすごく遅いので、環境がおかしい気がする。
100MBで10秒ならば、1GBで100秒かかるのも仕方ないでしょ?

あと、VACUUM FULLはアホのように遅いので、やるならCLUSTER。

385 :NAME IS NULL:2008/03/28(金) 17:00:26 ID:???
>>383
予備機はあるけどスペックが違うので大分遅いんです。
本番データは2GB強あるのでインポートするのも一苦労だし

>>384
そうなんだ。じゃあshared_buffersを全データが載るくらい増やせば
劇的に速くなると思うんだけど、postgresql8でも1GBくらいに性能ピークが
あるっていうのはなんでなの?

>100MBで10秒ならば、1GBで100秒かかるのも仕方ないでしょ?

select * じゃなくて select count(1)だから容量では単純比較できないと思う。
730万件が11秒ってなかなか優秀だと思ってたんだけどものすごく
遅いん?うーん。このスペックなら何秒くらいが妥当だと思う?
数十万件のテーブルから複雑な検索条件で検索かけるのとかは
軒並み1秒以内で終わるし、テスト環境(これもLinux)にくらべたら大分速いから、
環境のせいじゃないと思ってたんだけどなあ。

386 :NAME IS NULL:2008/03/28(金) 21:02:35 ID:???
見当外れなこと書いてたらスマソだが、
select count(*)にはできないのかな?
Postgreは知らんけどOracle8iではえらい差がでるよ。
count(1)ではDistinctのカウントになるので重複値の検出でえらい時間がかかる。
全件count(1)なんてやっちゃうと全件の中間テーブルを作ろうとしたりして。

387 :NAME IS NULL:2008/03/28(金) 21:08:15 ID:???
>>385 730万件が11秒
手元の環境だと、2秒未満。一昔前のデスクトップ機。
730万件だと最低250MB以上にはなるはずだし、なにか勘違いしてないか?

=# select pg_size_pretty(pg_relation_size('test'));
pg_size_pretty
----------------
252 MB
(1 row)

=# select count(1) FROM test;
count
---------
7300000
(1 row)

Time: 1876.152 ms


388 :NAME IS NULL:2008/03/28(金) 21:09:22 ID:???
>>386 残念だが見当外れ。
count(*)とcount(1)はまったく同じ動作です。

389 :NAME IS NULL:2008/03/28(金) 22:28:14 ID:???
>>388
あれ?同じ動作だったんだっけ?
昔なにかでcount(*)よりcount(1)の方が良いって記事をどこかで見た気がするんだが・・・。
勘違いか?

390 :NAME IS NULL:2008/03/28(金) 22:51:29 ID:???
>>387
ごめんそのpg_size_prettyを知らなくて、データのバイト数(1レコード36バイト)に
730万をかけて20〜30MBかなあと思ったんだけど、一桁間違えてた。
それやってみたら485Mだったよ。

360万件の方は3587MB
トータルのデータ領域が広すぎて遅くなってんのかな。
shared_buffersも1.5GBじゃ全然収まってないってことだね。
サービスインからしばらくVACUUMかけてなかったので、一回くらいは
VACUUM FULLかけたいんだけどね。

CLUSTERは調べたらテーブルロックしちゃうんだね。
夜中やってみるかな

391 :NAME IS NULL:2008/03/28(金) 23:06:44 ID:???
>>389
ユニークインデックスを持った列名の方がいいという記述なら見つけた

http://www.geocities.jp/mickindex/database/db_optimize.html#LocalLink6
http://oracle.se-free.com/tuning/B1_wild.html

でもって今日は325万件なんだけどやってみた
1. count(key) 76秒
2. count(1) 65秒
3. もう一回count(key) 63秒
4. selct count(*)が83秒

1の実行でキャッシュに載ったのかな。アクセスが割とある時間帯なので、
別要因で変動しているかも知れないけど


392 :NAME IS NULL:2008/03/28(金) 23:45:45 ID:???
>>389
他のDBMSだと効果があるのかもしれないけど、PostgreSQLに関しては関係ないのですよ。
あんまり鵜呑みにしないほうが良いのですよ。

393 :NAME IS NULL:2008/03/29(土) 20:05:32 ID:???
見当違いかもしれないが、HDD壊れてると遅くなったりしないか?

394 :NAME IS NULL:2008/03/30(日) 09:29:37 ID:7s6ei0XY
>>391

マシンの物理メモリ量と、DB全体のサイズの問題なのでは?メモリを
8Gくらいにすれば、あんましHDDにアクセスせずに済んで早くなると
思います

395 :NAME IS NULL:2008/03/30(日) 09:56:52 ID:???
>>391

オススメとしては、
・OSをCENTOS、x86_64にしてメモリを8Gくらいは積む。
・shared_buffersは1.5GのままでOK
・HDDを高速なものに交換する。

24時間365日について
・VACUUM FULLはロック掛かると思いますので、運用中は難しいかと。
・バージョンによっては、VACUUMがらみでバグがあったと思うので、
 結構不安。
 8.2系統だと、8.2.7のリリースノートに
 Repair potential deadlock between concurrent VACUUM FULL operations
on different system catalogs (Tom)
 って載ってるし、バージョンアップをすすめます。

 参考
 ttp://www.postgresql.org/docs/8.2/static/release-8-2-7.html

・OS再起動も、1ヶ月に1回くらいしたほうが良いのでは?


396 :NAME IS NULL:2008/03/30(日) 12:38:56 ID:???
ソフトやハードで力技で解決するよりは、
 ・VACUUMをちゃんとする運用にかえる
 ・count()を多用しない設計にする
ほうが重要だと思うのだが・・・

397 :NAME IS NULL:2008/03/30(日) 15:59:36 ID:???
8.3にしてVACUUMの必要性をなるべく減らすという手もある。
んまぁ、>>396の言うとおり、時間がかかるからVACUUMはしないというのは
腐った運用としかいいようがないけどね。

398 :NAME IS NULL:2008/03/31(月) 11:57:27 ID:NLL0Kbcv
テーブルは以下のようになっています。

TableName(
id serial,
up_id integer,
data text,
updatetime timestamp
);

このとき、up_id毎にupdatetimeが最新のものをリストしたいのですが、
どのようなSQL文を書いたらいいのでしょうか?
up_id 指定で1件取り出すだけなら以下のSQL文でいいのはわかるのですが
SELECT * FROM TableName WHERE up_id=? ORDER BY updatetime DESC LIMIT 1;

399 :391:2008/03/31(月) 12:10:22 ID:???
みんなありがじゅー。
VACUUM ANALYZEは毎日やってる。最初AUTOにしてたんだけど、
毎日10万レコードくらい追加/削除するのでデイリーでやるようにした。
count()するのは、一覧表示の時にまず全件カウントしてページング処理を
したいから避けられない。
HDDが遅いのはアレだと思ってたので、次のシステムではRAID0+1を提案した。

で、>>395
・メモリを8Gくらいは積む。
・shared_buffersは1.5GのままでOK

っていうのは、残りの6GBはOSのディスクキャッシュにおまかせするってこと?

400 :NAME IS NULL:2008/03/31(月) 12:29:58 ID:???
>>398
idとup_idの関係がイマイチ分からんのでkwsk

401 :NAME IS NULL:2008/03/31(月) 12:43:44 ID:???
>>398
てきとーに、
select up_id, max(updatetime) where tablename
gourp by up_id
と書いてみるテスト


402 :NAME IS NULL:2008/03/31(月) 12:44:24 ID:???
あ、whereじゃなくて、fromだorz

403 :NAME IS NULL:2008/03/31(月) 12:44:57 ID:???
あ、gourpじゃなくて、groupだ。
てきとーすぎるorz

404 :398:2008/03/31(月) 13:08:16 ID:???
ありがとうございます

>>401
idは主キーで、特に今回は使わないです(すみません)
up_idは他のテーブルと結合するためのidです(他のテーブルの主キーつまり一対多のテーブル)。
up_idはユニークではないので、up_id毎に複数レコードが存在します。

>>401
そのSQLでup_idとupdatetimeのリストは作れるのですが、
dataのカラムが取れないので、困ってしまうのです。
他のDBだと(本当は文法違反であるものの)、
取得カラムにdataを追加するだけで欲しいものが取得できたりするのですが、
PostgreSQLだとgroup byにもdataを追加しなければいけないので、
dataまで同一じゃないとうまくグループ化されません。

405 :NAME IS NULL:2008/03/31(月) 13:23:51 ID:???
>>404
up_id別の最新updatetimeを取得できるなら、
そのSQL(をVIEWにするなりして)と
元テーブルのJOINを取ればいいだろ。


406 :401:2008/03/31(月) 13:37:12 ID:???
まぁ、そういうことだな。

407 :NAME IS NULL:2008/03/31(月) 13:59:28 ID:???
>>404
何に困ってるんだ?
select tablename.*
from tablename
join (
select up_id,max(updatetime) as updatetime from tablename group by up_id
) tmp using(up_id,updatetime);


408 :398:2008/03/31(月) 14:03:41 ID:???
>>401,405
ありがとうございます。

ということは、自分のテーブルに自分のテーブルを
up_idとupdatetimeで結合する感じですよね。

なんか、こう珍しくなさそうな検索条件なので、
もっと単純な解決方法があるのかと思いまして。

409 :398:2008/03/31(月) 14:10:55 ID:???
>>407
ありがとうございます(すれ違いました)。
>>408の通りですが、usingという書き方は知りませんでした。
勉強不足ですね…。

410 :NAME IS NULL:2008/03/31(月) 15:14:44 ID:???
>>399
全件カウントなら・・・別テーブルでカウントしておいた方がよくないか・・・・?
引いてくる条件のバリエーションが多いと結局面倒になるだけだけど。

411 :NAME IS NULL:2008/03/31(月) 15:24:33 ID:cYc2EXId
PostgreSQL初心者です。
idを主キーにして、データはidの昇順に登録しておきました。
WindowsなのでpgAdminIIIのデータビューで見るとidの昇順にデータが見えます。
一方
SELECT id from table
とするとid昇順になっていないところがありました。
order byを使えばいいことは分かったので問題はないのですが、こういうことは十分起こりうることなのでしょうか?

412 :NAME IS NULL:2008/03/31(月) 15:28:25 ID:???
>>411
PostgreSQLに限らず一般的にそう。

413 :NAME IS NULL:2008/03/31(月) 15:28:39 ID:???
>>411

レコードの順序は保証されない。順序が重要ならば必ず ORDER BY すべし。




414 :411:2008/03/31(月) 15:35:57 ID:???
>>412,>>413
わかりました。どうもありがとうございます。

415 :NAME IS NULL:2008/03/31(月) 16:05:11 ID:???
>>410
結局はよく使う検索条件だけに絞って一瞬で検索できるようにしたんだけど、
それとは別に勉強のために数GBのデータを早くする方法無いのかなと
思ってさ。Oracleなら全部キャッシュにいれてしまえばいいんだろうけど、
PostgreSQLはキャッシュサイズ800MBにピークがあるって事だったので、
どうしたらいいかなと。

元々は操作する人が任意の検索条件を指定できるようになっていたので
レコード数を別テーブルで管理は無理だった。



416 :NAME IS NULL:2008/03/31(月) 21:03:41 ID:???
>>415
PostgresとOSでキャッシュ管理がダブるので、中途半端にメモリの半分とかしないほうがいい。
少なめにしておくか、むしろ限界まで割り当てるか、どっちか。

417 :NAME IS NULL:2008/03/31(月) 22:35:44 ID:???
pbbenchとか使って、テストをして決めればいいと思うが...

418 :NAME IS NULL:2008/03/31(月) 23:35:10 ID:???
>>399

>っていうのは、残りの6GBはOSのディスクキャッシュにおまかせするってこと?

そのとおりです。HDDから読むから遅いのであって、メモリからなら
OSキャッシュからでも、postgreSQLのメモリからでも大差ないと思います。


419 :NAME IS NULL:2008/04/01(火) 07:35:04 ID:???
>>417
テストをして決めるときの、パラメータ値の探索範囲の話をしているんだと思うよ。

420 :NAME IS NULL:2008/04/02(水) 09:25:18 ID:???
4GBのテーブルの全件カウントを速くしたいのでpgbenchは意味無いんです。
ベンチテストという意味ではそのselect count()の結果自体がテスト
なんだけど、本番稼働中にDB止めながらパラメータ変えつつ
テストするわけにもいかないし、とりあえずメモリ増設と設定パラメータ変更
(バッファ1.5GBとか)はやってみたので、みなさんの知恵を借りに来ました、
という感じです。


421 :NAME IS NULL:2008/04/02(水) 09:35:36 ID:???
もしかして「キャッシュサイズ800MBにピーク」っていうのも
テーブルサイズとか無視した単なる指標に過ぎなくて
環境によっては大きく変わるのかなあ。
例えば今回の場合だったら4GBキャッシュに割り当てた方がいいとか

参考にしたのはここ
http://itpro.nikkeibp.co.jp/members/ITPro/oss/20050402/158372/?P=2

422 :NAME IS NULL:2008/04/02(水) 10:20:27 ID:???
>>420
全部SSDにつっこめ。


423 :NAME IS NULL:2008/04/02(水) 10:50:22 ID:???
ネタにマジレスするのはなんだけど
業務用のシリコンディスクっつーのもあるよね
http://www.newtech.co.jp/products/silicon_s/ramsan/index.html

16GBで570万て


424 :NAME IS NULL:2008/04/02(水) 11:51:17 ID:???
>>421
全件カウントじゃ4GBがテーブル全部がキャッシュに乗っからないと劇的な変化はなさそうだし、
shared_buffersを4GB強にして試してみるのは悪くないと思う。

>>422
ランダムアクセス性能が非常に重要になるので、ランダムアクセスでは速いSSDは確かに
面白そうではあるけど、あっという間に寿命がくる罠…

425 :NAME IS NULL:2008/04/02(水) 15:03:01 ID:???
pgperlのソースを探してるのですが
フォーラムにも見当たりません。。
どなたかご存知ないでしょうか?

426 :NAME IS NULL:2008/04/02(水) 18:09:27 ID:???
4GBのテーブルってデータ保存期間が14日間だったんだけど、
30日に延長されたよ。今後はこのテーブルだけで8GBになる。
ちなみにデータ領域をdfでみると今10GBくらい。


427 :NAME IS NULL:2008/04/03(木) 11:29:13 ID:???
>>426
だからSSDに配置汁。

428 :NAME IS NULL:2008/04/03(木) 14:30:26 ID:???
トリガで常に件数どっかに置いておく、とか

429 :NAME IS NULL:2008/04/03(木) 22:18:13 ID:???
SSD買う金があったら、その金でメモリ買ったほうが良くね?

430 :NAME IS NULL:2008/04/04(金) 13:53:48 ID:???
>>429
でも、8GB以上メモリを積めるマシンはそれなりの価格になるぞ。

431 :NAME IS NULL:2008/04/04(金) 15:29:07 ID:???
SSD載せれるサーバもそれなりな価格になりそうだが^^;

最近とったメモリ大目の見積もりだと
クアッドコアのSMPでメモリ16GでSASの73GB(15000回転)でRAID10で
(保守とかその他オプションつけて)だいたい100万〜150万くらいだったかな

432 :NAME IS NULL:2008/04/04(金) 18:59:30 ID:???
結局のところ、426がどれだけ予算をかけられるのかによるからなぁ。

433 :NAME IS NULL:2008/04/08(火) 17:59:30 ID:JAlLqxhR
telnetでつないでpsqlでselect文だして、ちょっとした確認をすることが結構あります。
で、結果をマウスで選択、コピーして、使ったりしてるのですが、結果が多い時コピペが大変です。

そんな時、コマンドの>みたいにテキストに書き出すことはできないでしょうか?

434 :NAME IS NULL:2008/04/08(火) 18:19:36 ID:???
例えばtest.sqlというファイルにSQLを書いておいて

psql -U postgres test < test.sql > test.result

こうすればtest.resultに結果が書かれると思うんだけど
これじゃだめ?

435 :NAME IS NULL:2008/04/08(火) 18:24:54 ID:???
>>433
psql を -o オプション付きで起動するか
psql で \g ファイル名とするか。

こういう時は psql --help するか
psql で \? すれば大概分かるかと。

436 :NAME IS NULL:2008/04/08(火) 18:29:32 ID:???
\o

437 :NAME IS NULL:2008/04/09(水) 03:58:11 ID:???
teratermかpoderosaで繋いでログファイル指定しとく、とか
Windowsじゃなかったらアレか

438 :433:2008/04/09(水) 13:44:15 ID:vjpBiAeV
>>434
>>435
>>436
>>437
レスありがとうございます。

おっしゃる通り、ヘルプの存在をすっかり忘れてました。
失礼。

ログっていうのも手軽でいいですね。

439 :NAME IS NULL:2008/04/10(木) 00:56:47 ID:???
手がかかる方法としてはsshでつないでport forwardしてPgAdminつかうという手も

440 :NAME IS NULL:2008/04/16(水) 12:46:24 ID:xMO3l+R5
80万レコードほどあるテーブルの集計をとっているのですが
かなりコストがかかってしまい、15分ほどかかってしまっています。
単純なテーブル+単純なクエリなんですが、どこか改善できるポイントは
あるのでしょうか?
count_table
id|user_id|date

select user_id, count(*) AS Num from count_table
where date between '2008-01-01 00:00:00' and '2008-02-01 00:00:00'
group by user_id
order by Num desc

441 :NAME IS NULL:2008/04/16(水) 13:01:41 ID:???
>>440

date列にindexを張るとか?

442 :NAME IS NULL:2008/04/16(水) 19:52:51 ID:???
久しぶりに来たら進んでる・・・
>>306
そんなのSQLサーバ側で変わったら使えないと思ったんだが、
見た目文字列リテラルなのか、日付リテラルなのかは、コンテキスト次第だ
った・・

>>440
やっぱり、dateにINDEX張ってないと遅くなるね。って441と同じ意見であった。
データが膨らむからその時点でディスク容量が増えているか・・・。

INSERT系なら、
ttp://www.postgresql.jp/document/pg831doc/html/using-explain.html
で、幾分か速くなった。




443 :442:2008/04/16(水) 19:55:44 ID:???
補足: INSERT構文を最適化するのはこっちだった。。。
ttp://www.postgresql.jp/document/pg831doc/html/sql-prepare.html


444 :NAME IS NULL:2008/04/16(水) 22:27:02 ID:???
>>442
他には月ごとにパーティショニングしてみるとか。

445 :NAME IS NULL:2008/04/17(木) 16:28:11 ID:???
引っかき回すようで申し訳ないんですが
>>369-370
のような場合って、
on aa.code01=cc.code01 and cc.code002 =6

on aa.code01=cc.code01 and bb.code002 = cc.code002
という感じに変えて、最後にWHERE句でbb.code002 = 6
とやるのよりはやいの?

状況によりけりとは思うんだけど、どちらのほうがより安定しているのかな、とおもって。

446 :440:2008/04/17(木) 18:38:38 ID:???
>>441-442
アドバイスありがとうございます。
date にインデックスをはったら大分早くなりました。
というかめちゃくちゃ早くなりました。

447 :NAME IS NULL:2008/04/17(木) 22:19:51 ID:???
失礼します。
pg_dumpallから生成されたファイルから、ある一つのDBだけリストアしたい
場合、コマンドとしてどのように実行すればよいでしょうか?
テンパってます。。。


448 :NAME IS NULL:2008/04/17(木) 23:03:32 ID:???
-d オプションで指定してもだめでしたっけ?
最悪、ダンプファイルを開いて必要なとこだけ残してリストアする?

あまりお力になれず申し訳ない。

449 :NAME IS NULL:2008/04/17(木) 23:17:08 ID:???
>>448
ありがとう、試してみます。


450 :448:2008/04/17(木) 23:29:49 ID:???
いい案が思い浮かばないままですが、

postmasterのインスタンスをもう一個起動して、そっちに放り込んだあと
必要なDBだけのダンプファイルを作成するのはどうでしょう?

ダンプファイルを直接編集するよりは楽かもしれません。。。

451 :NAME IS NULL:2008/04/17(木) 23:38:56 ID:???
>>450
ありがとう、私もそれしか思い浮かびませんでした。
いったん別マシンのpostgresにフルで戻した後、必要なdbだけをdb_dumpして、
それを戻すようにしました。手間ですが、何とかなりました。

452 :NAME IS NULL:2008/04/18(金) 00:15:32 ID:???
>>451
何とかなったようでよかったです。
おつかれさま。

453 :NAME IS NULL:2008/04/18(金) 10:11:21 ID:TLsFyIeR
テーブルの主キーを変えるのってできませんか?

主キーを削除できればできそうですけど・・

お願いします。

454 :NAME IS NULL:2008/04/18(金) 10:56:55 ID:???
616 名前:NAME IS NULL[sage] 投稿日:2008/04/18(金) 03:12:10 ID:???
MySQL、新機能追加は有償版の「MySQL Enterprise」だけを対象に
http://www.technobahn.com/news/2008/200804172000.html

Linuxを代表するオープンソースベースのリレーショナルデータベース管理システムのMySQL
が近くソースコードの公開を停止する方向で準備を進めていることが16日、米カリフォル
ニア州サンタクララで開催中のMySQLコンファレンスの席上で明らかとなった。

455 :NAME IS NULL:2008/04/18(金) 11:06:32 ID:???
>>454
スレ違い

MySQL vs PostgreSQL Part2
http://pc11.2ch.net/test/read.cgi/db/1123011800/
こちらへどうぞ

456 :NAME IS NULL:2008/04/18(金) 11:14:49 ID:???
嫌気がさした人はこっちに来そうですねw

457 :NAME IS NULL:2008/04/18(金) 22:09:27 ID:???
ライセンスの問題からしてもこっちに移住する人は多いだろう

458 :NAME IS NULL:2008/04/18(金) 22:56:43 ID:???
呼び込み運動をさりげなくしましょうw

『なんか大変ですね。よかったらこっちも試してみませんか。』

459 :NAME IS NULL:2008/04/18(金) 23:01:55 ID:???
PostgreSQLの方がシンプルで好きなんだが・・・。
XOOPSが動けば、PostgreSQLに乗り換えたい。


460 :NAME IS NULL:2008/04/18(金) 23:13:45 ID:???
>>457
つーか、ライセンスのこと気にする人は最初からこっちにいるでしょ。

>>459
へ? 動かないの? XOOPS コミュニティってそんな低レベルな世界だったんだ。

461 :NAME IS NULL:2008/04/18(金) 23:19:07 ID:???
>460
PostgreSQLで動かしたことがあるのか?
推奨環境には、MySQLしかないようだが。

462 :NAME IS NULL:2008/04/18(金) 23:25:42 ID:???
>>461
何言ってるの?
XOOPS って MySQL に依存しまくりのコーディングしてるの?
なんという前時代的な。

にしたって、それくらい改造出来るだろって話。
実際やってる例もあるみたいだし。


463 :NAME IS NULL:2008/04/18(金) 23:29:47 ID:???
既知外ってなんでイキナリ喧嘩腰なんだろう。

464 :NAME IS NULL:2008/04/19(土) 01:18:47 ID:???
共有ロック/排他ロックってどうやんの?

465 :NAME IS NULL:2008/04/19(土) 06:28:53 ID:???
ロックなぞわざわざ「やる」ものではない。

466 :NAME IS NULL:2008/04/19(土) 09:32:09 ID:???
>>464
行ロックなら SELECT ... FOR SHARE/UPDATE
表ロックなら LOCK tbl IN SHARE/EXCLUSIVE MODE
>>465
MVCCあるからあんまり必要ないのは同意。
でも SELECT FOR UPDATE くらいは使わないといけないこともよくある。

467 :NAME IS NULL:2008/04/19(土) 12:14:16 ID:???
>>466
というより、SELECT FOR UPDATEはOracleやPostgresのように直接RRレベルを
サポートしないDBMSでRRが必要な場合に使うものと考えた方が良い。
下手にロックとか考えると、同期制御とごっちゃに理解して後々困ることになるからね。
OracleのRead Commitedは間違ってる、とかw

468 :NAME IS NULL:2008/04/19(土) 15:14:52 ID:???
RRって何?

469 :NAME IS NULL:2008/04/19(土) 15:17:10 ID:???
たぶん REPEATABLE READ

470 :NAME IS NULL:2008/04/20(日) 07:02:44 ID:???
>>425
>pgperlを使う方式(旧称 pgsql_perl5)
>1995年のpostgres95の時代からPostgreSQL7.2.3まで PostgreSQLのソースの含まれていた Perlインタフェースで,
>libpqに似せたシンプルなインタフェースデザインとなっています.
>libpqライブラリが必要です.

471 :NAME IS NULL:2008/04/22(火) 13:52:15 ID:qNcJmW6i
FETCHコマンドで
FETCH [ direction { FROM | IN } ] cursorname
とありますがFROMとINの違いってなんですか?

「INを使用するオプションはPostgreSQLの拡張です。 」としか書いてないし
実際に使ってみても同じ結果しか得られないし・・・


472 :NAME IS NULL:2008/04/22(火) 14:18:56 ID:???
>>471
FROMが標準語で、INはPostgreSQLの方言ってだけかと

473 :NAME IS NULL:2008/04/22(火) 17:12:16 ID:???
webページの言語をutf-8で作成してる場合は
PostgreSQLでもutf-8を使ったほうがいいんですか?
utf-8にしたことにより発生するエラーというものも有るんでしょうか?

474 :NAME IS NULL:2008/04/22(火) 23:14:06 ID:???
今は外字も入るし、utf-8にしてもデメリットないんじゃないかな。
基本的にはドライバが吸収するから、webサイトとDBの言語は
別々に考えていいよ。そして、どっちもutf-8にすべき。
諸事情でwebをSJISにする場合でもDBはutf-8で
いいんじゃないかな

475 :NAME IS NULL:2008/04/23(水) 00:32:56 ID:???
>>474
ありがとうございます!
統一できると、ローカル作業で言語切替の事を気にしなくていいのでよかったです

476 :NAME IS NULL:2008/04/23(水) 01:40:14 ID:???
DBのエンコードがなんだろうがクライアントと関係ないんじゃ?

477 :NAME IS NULL:2008/04/23(水) 10:52:33 ID:???
そうだな
まあ日本語以外のマルチバイト文字も考えなきゃならんときはUTF-8はありがたい

478 :NAME IS NULL:2008/04/23(水) 11:00:32 ID:???
思いつきだけど UTF-8 とそれ以外じゃソートしたときに結果違わね?

479 :NAME IS NULL:2008/04/23(水) 11:17:38 ID:???
ひらがなさえ同じならいいけどな
個別にソート用に表持たせることもあるかな

480 :NAME IS NULL:2008/04/23(水) 19:00:39 ID:???
将来、PostgreSQL のバージョンアップで、
int 型を検索するときに
c = 1 ではなく、' で括った
c = '1' がエラーになる可能性はありますか?

PostgreSQL 8.3 にしたところ、text 型のカラムを検索する場合

where foo = 1;

ではエラーになりました。

int 型は括っても括らなくても使えているのですが、
SQL の標準とか、将来的にどうなのかな、と疑問に思って。
ご存じの方、よろしくお願いいたします。

481 :NAME IS NULL:2008/04/23(水) 19:28:27 ID:???
>>480
↓が参考になるかも?
http://www.postgresql.jp/document/current/html/typeconv.html

個人的には
bigintとintとかtextとcharみたいにサイズが違う同じ型ならDBにまかせるけど
intとtextみたいに別物は明示的にキャストしてあげたほうがいいと思う。


482 :NAME IS NULL:2008/04/23(水) 19:45:46 ID:???
>>480
その書き方で大丈夫。
クォートされていると型の決定は文脈依存で、適当に変換される。

ちなみに、若干似てるけど、
Java で PreparedStatement#setInt() の代わりに setString() するのはダメよ。

483 :480:2008/04/23(水) 21:26:43 ID:mDsa5IzI
>>481-482
ありがとうございます。

create table test(
text text,
int int
);

というテーブルにおいて、
8.2 までは select * from test where text = 1 は問題なく、
8.3 からエラーになるようになりました。

int 型のカラムは 8.3 でも
select * from test where int = 1; -- (1)
select * from test where int = '1'; -- (2)
のどちらも問題ありませんが、
8.4 や 9.0 になって (2) がエラーになることはありますか。


484 :NAME IS NULL:2008/04/23(水) 23:01:02 ID:???
>>483
エラーにはならない。安心して (2) を使って大丈夫。

485 :NAME IS NULL:2008/04/24(木) 05:05:18 ID:???
>>8.2 までは select * from test where text = 1 は問題なく、

これが、問題なく使えていたのを初めて知った。
気になったので確認したら、数字だと通ってたんだな。

486 :NAME IS NULL:2008/04/24(木) 08:04:22 ID:???
>>485
正確には、型の不一致があったとき、両辺を勝手に text にキャストして比較していた。
where timestamp = 数字 とかも通っちゃってた。

いろいろと危険なので、変更されてよかったと思う。

487 :NAME IS NULL:2008/04/24(木) 13:49:37 ID:LtHVlG1o
>>484
数字は 1 でも '1' でも危険はないから
今後とも大丈夫、ということなのでしょうか?

488 :NAME IS NULL:2008/04/24(木) 22:01:50 ID:???
将来のことなので誰もなんとも言えないと思うけど、
可能性の話をするならエラーになる可能性はあるんじゃない?
もしくはエラーにはならなくてもtextで検索しにいくので
条件にマッチしない可能性とか

489 :487:2008/04/24(木) 22:40:07 ID:v9wdKkgn
確かに将来は分かりませんよね。
ありがとうございます。

SQL:1999 や SQL:2003 などの
SQL 標準的にはどうかご存知の方は
いらっしゃいませんか。

490 :NAME IS NULL:2008/04/24(木) 23:52:03 ID:???
それを知ってどうするつもりなんだろ。
ちゃんと型あわせるようにしておけば大丈夫なだけじゃん。

どんな言語でも「やっぱ暗黙のキャストやーめた」となる可能性は
0じゃないよ

491 :NAME IS NULL:2008/04/25(金) 00:02:58 ID:???
実行計画とると、解析後のSQL見られるけど
内部的にはかなりキャストしてるのが分かる

たいしたことは無いんだろうけど、表の結合条件でキャストが多いと
性能が落ちるかもしれんね

492 :NAME IS NULL:2008/04/25(金) 07:50:04 ID:???
>>491
リテラルなら、SQLパースのあと1回だけキャストされて、処理中はすでにキャスト後になっている。
性能を心配する必要は無いよ。

そもそも「数字」といったって、int2/4/8, float4/8, numeric と
いろいろあるんだから、'' で括らなくても何かしらの変換が挿入される可能性はある。

493 :NAME IS NULL:2008/05/04(日) 14:06:49 ID:???
8.3系で運用してる人いる?
過去バージョンと比較して使用感はどんなもんでしょうか

494 :NAME IS NULL:2008/05/07(水) 10:21:33 ID:AHN5+Ycn
ユーザ会からpostgresをダウンロードしようとすると

Internet Explorer ではこのページは表示できません

になってしまいますが、サーバがこけてますか

495 :NAME IS NULL:2008/05/07(水) 10:40:52 ID:???
他のミラーから取ってきたら?

ftp://ring.ocn.ad.jp/pub/misc/db/postgresql/

496 :NAME IS NULL:2008/05/07(水) 11:25:58 ID:???
>>495
いけました。ありがとう。

497 :NAME IS NULL:2008/05/07(水) 14:23:09 ID:???
>>493
8.2でパフォーマンスが凄く悪かったサーバが見違えるようによくなった。
他のサーバもそこそこ改善してるし今のところ人為的なのを除きトラブルはない。
無茶といわれてた大量UPDATEに耐えられるかな?
できるならそういうコードも書きたいのだが・・・

498 :NAME IS NULL:2008/05/07(水) 14:46:10 ID:???
>>497
是非試していただければと思います。

499 :NAME IS NULL:2008/05/07(水) 17:10:05 ID:???
Windows版のPostgreSQLを自動インストールする方法はありますか?
Windowsの他のプログラムから、インストーラを起動して自動的にイン
ストールできるようだといいのですが。



500 :NAME IS NULL:2008/05/07(水) 17:38:32 ID:???
>>499
http://pginstaller.projects.postgresql.org/silent.html

501 :NAME IS NULL:2008/05/07(水) 18:30:16 ID:???
>>497

具体的に8.2ではいけなかった処理ってなんとなく尻尾つかめてたりするのでしょうか・・?

502 :NAME IS NULL:2008/05/07(水) 21:34:20 ID:Lqr18+2G
postgresql8.2のSQLで質問があります。

lent /*貸し出し管理*/
+id
+bookid 書籍ID
+lentdate 貸し出し日

book /*書籍*/
+id
+name 書籍名
+fromdate 有効期間(開始日)
+todate 有効期間(終了日)

select lent.lentdate, lent.bookid, min(book.name), count(*) as lent_count
  from (
    select lent.id, lent.bookid, ... from lent, ... where 条件1
    union
    select lent.id, lent.bookid, ... from lent. ... where 条件2
    ) lent
  left outer join book on lent.bookid = book.id and lent.lentdate >= book.fromdate and lent.lentdate <= book.todate
group by lent.lentdate, lent.bookid

本当は、グルーピングしたlent.lentdateの最小値の日付でbook.nameを取得したいのですがやり方がわかりません。
仕方なく、下記のようにbook.fromdate || book.nameで取得して、フェッチ後にbook.nameだけ切り出そうと考えました。
select lent.lentdate, lent.bookid, min(book.fromdate || book.name), count(*) as lent_count
  from (
    select lent.id, lent.bookid, ... from lent, ... where 条件1
    union
    select lent.id, lent.bookid, ... from lent. ... where 条件2
    ) lent
  left outer join book on lent.bookid = book.id and lent.lentdate >= book.fromdate and lent.lentdate <= book.todate
group by lent.lentdate, lent.bookid

しかしmin(book.fromdate || book.name)でグルーピング単位の最小値の値が返ってきません。ちょっと考えられない結果です。
試しにインラインビューの中のunionをやめてみたら、期待した値が返ってきました。
select lent.lentdate, lent.bookid, min(book.fromdate || book.name), count(*) as lent_count
  from (
    select lent.id, lent.bookid, ... from lent, ... where 条件1
    ) lent
  left outer join book on lent.bookid = book.id and lent.lentdate >= book.fromdate and lent.lentdate <= book.todate
group by lent.lentdate, lent.bookid

unionがいけないのか特定したくて、うまくいった条件1の方のSQLをunionで2本繋いでみるとNG(minの結果が変)になりました。
select lent.lentdate, lent.bookid, min(book.fromdate || book.name), count(*) as lent_count
  from (
    select lent.id, lent.bookid, ... from lent, ... where 条件1
    union
    select lent.id, lent.bookid, ... from lent, ... where 条件1
    ) lent
  left outer join book on lent.bookid = book.id and lent.lentdate >= book.fromdate and lent.lentdate <= book.todate
group by lent.lentdate, lent.bookid

・インラインビューの実体がunionで繋がれた複数SQLであること
・そのインラインビューでグルーピングすること
・そのインラインビューに外部結合した値をmin()関数で取得すること

この辺でpostgresqlの制限に引っかかっているようなことがありませんでしょうか?

503 :499:2008/05/07(水) 23:29:35 ID:???
>>500さま
英語の方に解説があったのですね。
もう少しぐぐり方を工夫する事を覚えようと思います。
ありがとうございました。


504 :NAME IS NULL:2008/05/08(木) 09:31:00 ID:???
>>502
min(book.fromdate || book.name) の部分で、日付が yyyymmdd に変換されると
期待してそうだけど、ちゃんと動作している?
単に、group by に book.name を含めるべきなのでは?

> minの結果が変
「変」とか「おかしい」とか言われても、助けられない。
具体的にどうなったのか、説明して欲しい。

505 :NAME IS NULL:2008/05/08(木) 12:59:40 ID:???
>>504
レスどうもです。book.fromdatはchar(8)でYYYYMMDDの文字列が入っています。
>単に、group by に book.name を含めるべきなのでは?
book.nameは集約したグループの中でmin()を使って取得したいのでgroup byには含めないと思います。

「minの結果が変=グルーピング単位の最小値の値が返ってきません。」です。すみません。
「book.fromdate || book.name」の値が下記のような場合、
20080501書籍01
20080502書籍02
min()で"20080501書籍01"が取得されることを期待しましたが、"20080502書籍02"が返ってきています。
ちなみにmax()にすると"20080502書籍02"が返ってきます。(;・∀・)

インラインビューの中身を切り出して単独で実行してみると
    select lent.id, lent.bookid, ... from lent, ... where 条件1
    union
    select lent.id, lent.bookid, ... from lent, ... where 条件1
必要なデータは取得されていることを確認しました。

group byを外して、全件そのまま出力させてみたら
20080501書籍01
20080502書籍02
の両方のレコードが取得されていることも確認できました。
あとはmin()で"20080501書籍01"が返ってくれさえすればOKなのですが。。

506 :NAME IS NULL:2008/05/08(木) 13:15:26 ID:???
>>505
unionとか関係無しに単純に文字列のminとmaxをやったらどうなるの?
encodingは?

507 :NAME IS NULL:2008/05/08(木) 13:55:21 ID:???
>>506
min(book.fromdate)とmin(book.name)を追加して実行すると
select lent.lentdate, lent.bookid, min(book.fromdate), min(book.name), min(book.fromdate || book.name), count(*) as lent_count
  from (
    select lent.id, lent.bookid, ... from lent, ... where 条件1
    union
    select lent.id, lent.bookid, ... from lent. ... where 条件2
    ) lent
  left outer join book on lent.bookid = book.id and lent.lentdate >= book.fromdate and lent.lentdate <= book.todate
group by lent.lentdate, lent.bookid

min(book.fromdate) min(book.name) min(book.fromdate || book.name)
20080501 書籍02 20080502書籍02
というおかしな結果になります。min(book.fromdate)だけは正しい結果が返ってきてますね。

DBのエンコーディングはEUC_JPです。

508 :NAME IS NULL:2008/05/08(木) 13:57:57 ID:???
すみません。>>505に誤りがありました。
誤:ちなみにmax()にすると"20080502書籍02"が返ってきます。
正:ちなみにmax()にすると"20080501書籍01"が返ってきます。


509 :507:2008/05/08(木) 14:03:26 ID:???
進展がありました。book.nameの値から全角文字を除去してみたところ
書籍01→01
書籍02→02

min(book.fromdate) min(book.name) min(book.fromdate || book.name)
20080501 01 2008050101

正しく集計されました。
もしかしてmin()関数の引数に全角文字が含まれるとおかしな動きをする、とかありますか?



510 :NAME IS NULL:2008/05/08(木) 14:06:09 ID:???
book.fromdate || book.name
20080501書籍01
20080502書籍02

min(book.fromdate || book.name)
この場合、先頭の8文字で大小比較が完了するので、全角文字までの評価は行われないだろうと期待していましたが、
>>509の結果を見ると、そうでもなさそうですね?

511 :NAME IS NULL:2008/05/08(木) 14:53:27 ID:???
>>509
どんな漢字が含まれるとmin()の動作に影響を与えるのか調べてみました。
「総合」が含まれていると×なようです。
どうも>>502の長いSQLは関係なかったようで、試しにbookテーブル単体で
select id, name from book
01, 総合20080501
01, 総合20080502

select id, min(name)
from book
group by id
01, 総合20080502 が返って来ました。ガーン。postgresqlのmin()関数が全角文字をサポートしていない?
>>502の代替手段がなくて困っています。

512 :NAME IS NULL:2008/05/08(木) 15:02:03 ID:???
DBのEncodingはどうなってるの?

513 :NAME IS NULL:2008/05/08(木) 15:10:32 ID:???
>>512
>>507

514 :NAME IS NULL:2008/05/08(木) 15:27:32 ID:???
--no-locale付けた?

515 :NAME IS NULL:2008/05/08(木) 15:42:59 ID:???
>>514
分かりません。Windows版なんですけど、付けたかどうかを確認する方法ってありますか?
でも、なんかビンゴっぽいですね。

516 :NAME IS NULL:2008/05/08(木) 16:02:08 ID:???
>>515
Windowsかあ。createdbはどうしたの?インストール時ならチェックする項目あったかなー。

SELECT name,setting FROM pg_settings WHERE name ~ '^lc';
とかどう?


517 :NAME IS NULL:2008/05/08(木) 16:04:40 ID:???
>>516
name setting
"lc_collate" "Japanese_Japan.932"
"lc_ctype" "Japanese_Japan.932"
"lc_messages" "Japanese_Japan.932"
"lc_monetary" "Japanese_Japan.932"
"lc_numeric" "Japanese_Japan.932"
"lc_time" "Japanese_Japan.932"
でした。ダメ?

518 :NAME IS NULL:2008/05/08(木) 16:05:54 ID:???
あとは、pg_controldata コマンドでもいい。

519 :NAME IS NULL:2008/05/08(木) 16:06:32 ID:???
>>517
noにすれば、そこは C になるはず。
noにしないとソート順狂うから、それだろうね。

520 :NAME IS NULL:2008/05/08(木) 16:15:06 ID:???
>>519
ありがとうございます!
ちなみにinitdbからやり直さないとダメなんですよね。キッツイなぁ。createdb毎に指定できないものか。。

521 :NAME IS NULL:2008/05/08(木) 16:28:19 ID:???
pg_dumpall ですぐだべ

522 :NAME IS NULL:2008/05/08(木) 17:01:28 ID:???
>>521
やってみます!

523 :NAME IS NULL:2008/05/08(木) 17:24:44 ID:???
ロカールの話で盛り上がっているようですが、
そもそもそれに依存しない抽出方法があるような気がします。

それぞれの本ごとに、一番古い貸し出し日および冊数を出したいのですよね?

524 :NAME IS NULL:2008/05/08(木) 17:28:36 ID:???
切れてしまいました。

以下のような頻出事例と似てるような気がします。
http://pc11.2ch.net/test/read.cgi/db/1193486961/35-36

525 :NAME IS NULL:2008/05/08(木) 17:30:31 ID:???
>>521
C:\>pg_dumpall -U postgres > pg_dumpall-20080508.dmp
postgresサービス停止
C:\>cd \postgres
C:\>mv data data-old
C:\>initdb --encoding=EUC_JP --no-locale -D C:\postgres\data
postgresサービス起動
C:\>psql -f pg_dumpall-20080508.dmp postgres
psql: could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "???" and accepting
TCP/IP connections on port 5432?
C:\>netstat -a | grep 5432
postgresサービスが立ち上がらなくなってしまった!?

526 :NAME IS NULL:2008/05/08(木) 17:35:10 ID:???
>>523
>それぞれの本ごとに、一番古い貸し出し日および冊数を出したいのですよね?
一番古い貸し出し日は抽出対象ではないのですが、
bookテーブルが世代管理されているので(同一idでfromdateとtodateで管理)
一番古い貸し出し日の時のbook.nameを世代を見て抽出したいのです。

527 :NAME IS NULL:2008/05/08(木) 17:43:12 ID:???
>>525
postgresql.conf を data-old から data にコピーすればいいと思う。

528 :NAME IS NULL:2008/05/08(木) 17:43:40 ID:???
>>525
そういうときは、ログとpostgresql.confをよく嫁

529 :NAME IS NULL:2008/05/08(木) 18:58:28 ID:???
>>527 >>528
お騒がせしました。パニクって再インストールしてしまいましたw そしてその再インストールでも小一時間ハマってました。

ロケールをCにして再度SQLを実行したら期待通りの結果が返ってきました!!アドバイスをくれた皆さん本当にありがとうございました。

530 :NAME IS NULL:2008/05/08(木) 22:31:42 ID:???
合わない locale と encoding を使ってしまうのは、頻出ミスだった。
v8.3 からは適合しない組み合わせはエラーが出力されるようになったので、
うっかりミスも減らせるはず。

531 :NAME IS NULL:2008/05/08(木) 23:12:35 ID:???
ついに対策されたんだw
石井さん乙?

532 :NAME IS NULL:2008/05/08(木) 23:25:38 ID:???
8.3リリースノートより:
> サーバのロケール設定と矛盾するデータベース符号化方式を不許可としました。(Tom)


533 :NAME IS NULL:2008/05/09(金) 00:38:51 ID:???
テーブルの中の特定カラムを、AESとか、desとかで、暗号化する事って出来るんでしょうか?
プログラムで行えば出来るのは解っているのですが、
一部一致検索で、ひっかからなくなって困ってしまいました。
そこで、PostgreSQL自体で暗号化する方法があれば、部分一致検索も
正しく動作するのか?と考えました。
だれか、こんな事をやった事ないですか?

534 :NAME IS NULL:2008/05/09(金) 00:45:42 ID:???
これ?
ttp://osb.sraoss.co.jp/PostgreSQL/Manual/PostgreSQL-8.0-ja/encryption-options.html

特定の列に関する暗号化

/contrib関数ライブラリ pgcryptoにより、あるフィールドを暗号化して保存することができます。データの一部が極秘データであるような場合に有用です。クライアントが提供した複合化用のキーで、サーバ上のデータを複合化し、クライアントに返されます。

複合化されたデータと復号化用のキーは、復号処理中およびクライアントサーバ間の通信中サーバ上に存在します。このため、データベースサーバへの全てのアクセス権限を持つユーザ(例えばシステム管理者)によって、データとキーが盗まれる瞬間があります。

535 :NAME IS NULL:2008/05/09(金) 01:53:57 ID:???
>>532
トム。。。

536 :NAME IS NULL:2008/05/09(金) 07:54:44 ID:???
>>533
部分一致検索したいのなら、ファイルシステムレベルで暗号化しないとだめ。
ただ、SELECT * で普通に元の値を取得できてしまうのが難点かも。

pgcryptoのような方式で、部分一致検索できるようにしてしまうと、
暗号化の強度としてはゼロに等しい。難読化くらいの価値しかない。
大小の順序を保つ必要があるので、二分検索で簡単に特定されちゃう。

537 :NAME IS NULL:2008/05/09(金) 08:42:47 ID:???
>>536>>534

こういう話出す人はもう少し暗号の勉強をして、表現力を養ったほうがイイよね。
権限を持つ者がデータを持っていけるのは、暗号とは相関性が無いんだよ。
無駄に暗号強度とか持ってくるから、「説得力があると騙される無知な人も居る」と覚えておこう。


538 :NAME IS NULL:2008/05/09(金) 16:32:04 ID:???
create table members (
id integer primary key auto_increment,
name varchar(256) not null,
birth date,
gender char(1) not null
)

というテーブルがあって、birth と gender でグループ分けしたいとき、どうしたらいいですか。
select birth, gender from members group by birth, gender だと id が分からず、
select id, birth, gender from members group by birth, gender だと エラーだし、
どうしたらいいんでしょう?



539 :NAME IS NULL:2008/05/09(金) 17:20:05 ID:???
何がしたいのかによる。
birthとgenderでグループ化したらそのグループに複数のidが含まれる可能性があるから
そのまま出すのは無理。
最大値 max(id) とか、一つに特定できるのならばそれが使えるけど。

540 :NAME IS NULL:2008/05/09(金) 18:00:55 ID:???
>>539
ですよねー
やりたいのは、まさにグルーピングであり、複数のidをグループごとにとりだしたいんです。
でもSQLではなんかうまくできなくて...すごく不自由しています。
こんなとき、みなさんどうしてますか。やっぱりPL/SQLとか使わないといけないんですかね。

541 :NAME IS NULL:2008/05/09(金) 18:13:23 ID:???
複数idが必要ならグループにする理由がないのでは?
具体的に、どんなデータからどんなデータを抽出したいのか書いてくれればわかるかもしれん

542 :NAME IS NULL:2008/05/09(金) 18:51:20 ID:???
select id, birth, gender from members order by birth, gender
とか?

543 :NAME IS NULL:2008/05/09(金) 19:17:14 ID:???
元のデータ
 id | name |  birth  | gender
------------------------------
1 | test1 | 2008-05-09 | M
2 | test2 | 2008-05-10 | F

抽出結果
 ?? | ?? | ?? 
--------------
x | xxxx | xx
x | xxxx | xx

こんな感じに

544 :NAME IS NULL:2008/05/09(金) 20:39:07 ID:???
>>537
で、あなたはいったいなんの役に立っているの?

545 :NAME IS NULL:2008/05/10(土) 02:51:14 ID:???
>>543
抽出結果が伏せ字だらけ、、、はっ!これが暗号ってやつDESか?

546 :NAME IS NULL:2008/05/10(土) 08:50:59 ID:???
>>538
idを配列として取り出してみては?
http://www.postgresql.jp/document/current/html/xaggr.html
のarray_accumを参考に。

547 :NAME IS NULL:2008/05/10(土) 13:49:28 ID:???
>>537

>>534はドキュメントのコピペですよ。

どの経路をどういう目的で暗号化したいかによって全然変わってくると思う。
>>533の文面から察するに、ディスク上のデータを暗号化したいだけで、サーバ上のメモリとか通信路の上では暗号化されなくてもいいみたいだし。

548 :NAME IS NULL:2008/05/10(土) 23:13:17 ID:???
>>547

> >>534はドキュメントのコピペですよ。
それは見れば解る。

> どの経路をどういう目的で暗号化したいかによって全然変わってくると思う。
> >>533の文面から察するに、ディスク上のデータを暗号化したいだけで、
> サーバ上のメモリとか通信路の上では暗号化されなくてもいいみたいだし。

キミに知識があるのは理解したけど、
具体的な部分を引用で誤魔化しただけじゃ意味が無い。

>>533みたいな質問を恥ずかしくなくできる程度だと、
その引用が役立つとは思えない。
暗号の基礎を学ぶ方が先決と感じるけどね。


549 :NAME IS NULL:2008/05/10(土) 23:41:57 ID:???
>>547

部分一致検索が出来る方法を探していたので、
メモリー上や通信経路上での暗号は別問題って事で。

534や536のpgcryptoを試してみます。


550 :NAME IS NULL:2008/05/11(日) 16:40:36 ID:nKIrUfLq
postgresqlをlinuxにインストールしてみましたが、
jdbcがありませんでした。
jdbcのみインストールできるサイトはありませんか?

よろしくお願いいたします。

551 :NAME IS NULL:2008/05/11(日) 18:12:16 ID:hAgtRqsE
>>550
本家->downloadでDLのページいってみては?

552 :NAME IS NULL:2008/05/11(日) 18:44:24 ID:???
複数のサーバに分散させてたアクセスログテーブルを一サーバにまとめる
作業をしてるのだけど、IDカラムをPRIMARY KEYにするために
数字を重ならないように振り直す良い方法ない?

連番である必要はないのだけど、
UPDATE id = nextval('foobar_id_seq');
だとトランザクションが完了までにストレージの容量不足であぼ〜ん。

データベースが500Gでストレージ容量が800Gな感じ。
行数はpgAdminの概算で10億のオーダー(実際にもたぶんそんなもん)。
Intel 8コア2Ghz、メモリ6Gで丸一日動かすぐらい以下で終わるとうれしい。


553 :NAME IS NULL:2008/05/11(日) 19:33:49 ID:???
>>548
暗号の基礎というのが想像つかないけど、公開鍵暗号とか、ハッシュ関数?AliceとかBobがいて、…みたいなことかな。
よかったらポインタとかキーワードください。

部分一致検索「できない」ところに暗号化する意味があるといえばあると思うんだけど、暗号化されたままのデータに対するプログラムによる処理、という研究領域もあったような。
まだ実用段階ではないはず。


554 :NAME IS NULL:2008/05/11(日) 20:59:34 ID:???
>>552
250GBぶん処理 → VACUUM → 残りの250GBを処理
で、750GBぎりぎりに収められるような気はするけど、効率的では無いね。

オリジナルの各サーバからデータをダンプすると思うのだけれど、
そのときについでにIDを再割り振りしてはいかがでしょ?
COPY (SELECT ID + <サーバごとのオフセット>, <ID以外の属性> FROM tbl) TO ...
みたいな。


555 :NAME IS NULL:2008/05/11(日) 21:49:59 ID:???
>>554
レスどうもです。
すでにpg_dumpでテーブルを圧縮ダンプしてオリジナルを消してしまって
いるのですが、書き戻しつつまったりやってみます。

スタンドアロンで起動してチョメチョメするとUPDATEがトランザクションを
作らずできるとかあると良かったのですが。


556 :NAME IS NULL:2008/05/11(日) 22:49:47 ID:nKIrUfLq
>>551
このやり方だとすべてをインストールしなければならないですよね?
jarファイルだけほしいんですが・・

557 :NAME IS NULL:2008/05/11(日) 23:05:40 ID:???
>>556
つ 本家 [ttp://jdbc.postgresql.org/]

558 :NAME IS NULL:2008/05/12(月) 00:19:43 ID:???
新しい列を追加してサーバID+IDカラムを主キーにすれば?

559 :NAME IS NULL:2008/05/12(月) 02:57:40 ID:???
>>548

>>534はpostgres標準でカラムごとに暗号化する方法が用意されてるよ
というポインタを出しただけだろう。なんでそんな喧嘩腰なん?




560 :NAME IS NULL:2008/05/12(月) 13:03:06 ID:???
>>543
せめてどの列に何のデータが欲しいかくらい書いて下さい。

561 :NAME IS NULL:2008/05/12(月) 14:25:10 ID:???
>>560
>>543は質問者への例だよ。
質問者が>>542みたいなこと書くからさ。

562 :NAME IS NULL:2008/05/12(月) 16:11:58 ID:???
>>561
ごめんよ('A`)

563 :NAME IS NULL:2008/05/12(月) 19:38:57 ID:???
wal_sync_methodをfsync,open_sync,fdatasyncの3つで試したのですが
以下の通りほぼ同じ数字なのですがこの場合どれを使えばいいのでしょうか?

■fsync
tps = 1027.689818 (including connections establishing)
tps = 1209.468247 (excluding connections establishing)

tps = 1034.481365 (including connections establishing)
tps = 1216.056506 (excluding connections establishing)

tps = 752.244097 (including connections establishing)
tps = 845.057033 (excluding connections establishing)

■open_sync
tps = 1052.034042 (including connections establishing)
tps = 1242.544732 (excluding connections establishing)

tps = 1028.417258 (including connections establishing)
tps = 1211.121120 (excluding connections establishing)

tps = 1019.530379 (including connections establishing)
tps = 1204.729693 (excluding connections establishing)

■fdatasync
tps = 775.081298 (including connections establishing)
tps = 873.168620 (excluding connections establishing)

tps = 1016.433399 (including connections establishing)
tps = 1197.497231 (excluding connections establishing)

tps = 1022.273040 (including connections establishing)
tps = 1208.232215 (excluding connections establishing)


564 :NAME IS NULL:2008/05/13(火) 23:21:07 ID:???
Direct I/Oが効くからopen_syncでいいんじゃね?
たまにバグ持ちのOSもいるけど。

565 :NAME IS NULL:2008/05/14(水) 16:50:51 ID:???
VACUUM FULLをやるとすごい時間かかると聞いていたけど、3分くらいで終わってしまった。
テーブルは200個くらいで、多いテーブルでもレコード数は20,30万レコードくらい、大半は数千、数万程度
これってだいぶ少ない感じだからかな?それともdumpを戻してからあまりデータが更新されてないから
汚れてないってことで早かったんですかね?
後、VACUUM FULL テーブル名って感じでテーブルのみ指定できるけど、これを
全テーブルやれば、VACUUM FULLやったときと変わらないのでしょうか?

566 :NAME IS NULL:2008/05/14(水) 19:31:16 ID:???
>>565
>dumpを戻してからあまりデータが更新されてないから
> 汚れてないってことで早かったんですかね?

> これを全テーブルやれば、VACUUM FULLやったときと変わらないのでしょうか?

いちいちその通りでなにも返す言葉がない


567 :NAME IS NULL:2008/05/16(金) 22:29:54 ID:???
sequenceの値を自分で設定することは出来ますか。
今は 1 から始まっているのをたとえば10000から始めたいんですが。

568 :NAME IS NULL:2008/05/16(金) 22:51:10 ID:???
ttp://ash.jp/db/pg_use.htm
答えを知らない俺がググって10秒で分かる内容を質問する勇気に感心した。

569 :567:2008/05/16(金) 22:57:55 ID:???
自己レスです。setval()関数でできるようです。


570 :567:2008/05/16(金) 22:58:21 ID:???
>>568
すみません

571 :NAME IS NULL:2008/05/17(土) 00:28:43 ID:???
使用環境はXPなんですが
COPYでテーブルのデータを全てCSVに落としたいのですが
文字列が2重引用符で囲まれなくて困っています。

COPYの説明読む限り、デフォルトは2重引用符となっています。
QUOTEで直接指定しても変わりありません。

572 :NAME IS NULL:2008/05/17(土) 09:40:53 ID:???
>>571
FORCE QUOTE

573 :NAME IS NULL:2008/05/17(土) 13:30:17 ID:???
FORCE QUOTEってカラム指定しないと駄目ですよね?
文字列だけ指定した引用符で囲いたいんですが
単純にQUOTEだとNULL文字だけしか引用符で囲ってくれないんです。

574 :NAME IS NULL:2008/05/17(土) 13:54:31 ID:???
文字列型のカラムを全部指定すればいいじゃん。

575 :NAME IS NULL:2008/05/17(土) 17:56:34 ID:???
集約関数のパラメータとなるような複数行のデータを表現する式というのはありますか?

こういう感じのことをしたいのですが

SELECT * FROM TABLE1 ORDER BY MAX(COL1,COL2,COL3); // COL1〜3のなかで最大の値を取りたい



576 :NAME IS NULL:2008/05/17(土) 17:57:02 ID:UrIKqt4y
しまった。
習慣でsageてしまった・・・

577 :NAME IS NULL:2008/05/17(土) 18:58:10 ID:???
>>575
greatest() かな。max(greatest(col1, col2, col3))

578 :NAME IS NULL:2008/05/19(月) 20:51:28 ID:KbQaa3g3
2chのような掲示板を作ろうと、以下のテーブル構成を考えています。
この場合、連番はどうやって取るのがスマートでしょうか?

板(板No、・・・)
スレッド(板No、スレッドNo、・・・)
レス(板No、スレッドNo、レスNo、・・・)

板Noはシーケンスでいいとして、スレッドNoとレスNoの取り方で迷っています。
Max(レスNo) + 1で取るのがいいか、発番テーブルを作るのがいいか。
あるいはもっとスマートなやり方があるのでしょうか。

アドバイスお願いします。

579 :NAME IS NULL:2008/05/19(月) 22:29:57 ID:???
スレッドも(big)serial型でいいんじゃ?規則正しく連続してる必要ないよね?
insert 〜 select 〜でいいんじゃない?
発番号テーブルとか作ってわざわざ整合とりにくくする必要性無いと思う

580 :NAME IS NULL:2008/05/20(火) 01:06:45 ID:yIeco2cc
あいうえお<br><h1>かきくけこ</h1>

というデータが入っていたとしまして、SQLでこのタグ(<>で囲まれている文字列)を省き、

あいうえおかきくけこ

として検索できるようにする方法はありますでしょうか。
もしありましたらご教示いただけますと幸いです。

宜しくお願いします。

581 :NAME IS NULL:2008/05/20(火) 02:47:41 ID:???
>>580
> SQLでこのタグ(<>で囲まれている文字列)を省き、

regexp_replace(データ,'<.*?>','','g')

582 :NAME IS NULL:2008/05/20(火) 09:41:17 ID:???
取り出してからの切った貼ったですかね。

583 :NAME IS NULL:2008/05/21(水) 09:35:37 ID:LdhCgnd0
よろしくお願いします。

金額を入れるカラムは、精度の高いnumericを使用した方がよいと聞いたのですが、
マニュアル等で調べたところ、そのカラムに整数しか入らない場合はinteger等で十分のような気がするのですが
この考え方で合っていますでしょうか?


584 :NAME IS NULL:2008/05/21(水) 09:58:22 ID:???
10/3*3とか?

585 :583:2008/05/21(水) 11:52:47 ID:???
>>584
確かにその場合は小数点があるのでnumericが必要ですよね。
必ず整数しか入らない前提の場合はintegerでも良いと思ってよいでしょうか。

「精度」の意味がよく分かっていないかもしれませんが、
整数しか格納しないのであれば、numericもintegerでも計算で誤差は生まれないと
思っているのですが。。

586 :NAME IS NULL:2008/05/21(水) 13:33:19 ID:???
SQLで計算はしないのか?

587 :583:2008/05/21(水) 17:20:11 ID:???
>>586
SQLで計算はしないOR計算しても小数点が出ないという前提です。

588 :NAME IS NULL:2008/05/21(水) 20:30:49 ID:???
>>583
numericが「何と較べて」精度が高いのか聞かなかった?

真数値: numeric integer
概数値: real float

あと、「精度」といっているのが誤差の少なさなのか
有効数字のことなのか。

「金額〜」という文脈で精度のことを言うときは、上記の
真数値である(誤差がない)ことを言う場合が多い。

589 :NAME IS NULL:2008/05/22(木) 07:29:35 ID:???
そもそも、通貨って円だけじゃないし
日本でも銭まで必要なこともあるし

そういうのを踏まえて必要かそうでないか判断しては


590 :583:2008/05/22(木) 10:19:23 ID:???
>>588,589
レスありがとうございます。

元々、素人DB設計者がnumeric(10,0)としていたので
突っ込んでやりたいなと思って質問しました。

>numericが「何と較べて」精度が高いのか聞かなかった?
金額の計算をする時、integer等と比較しての話として精度が高いと聞きました。

なので、「精度」は
>真数値である(誤差がない)ことを言う場合が多い。
こっちのことだと思います。

>日本でも銭まで必要なこともあるし
情報小出しですいません。
私も、numericを使うことに異論は無いのですが、
もともとのカラムがnumeric(10,0)だったんです。。

「精度が高い」と人から聞いただけで、「精度」の意味も考えずに
numeric型を採用しているDB設計者に対して
「小数以下格納しないならintegerでいいじゃないですか」という理由が欲しかった次第です。

低レベルな話ですごく申し訳ないです。。

591 :NAME IS NULL:2008/05/22(木) 10:48:29 ID:???
整数としてしか扱わない、というのなら整数でもいいんじゃない?
金額を扱う場合はnumericと決めている、のならnumericでもいいし。

592 :NAME IS NULL:2008/05/22(木) 12:10:45 ID:???
numericだのintegerだの云々言いたい583は、当然
ttp://ja.wikipedia.org/wiki/%E4%BA%8C%E9%80%B2%E5%8C%96%E5%8D%81%E9%80%B2%E8%A1%A8%E7%8F%BE
あたりの知識はあるんだよな?

まあ、ヲレはPostgreSQLでnumericがどう実装されているか知らないけどさ。

593 :NAME IS NULL:2008/05/22(木) 21:03:28 ID:???
整数を扱うとき、numeric型とinteger 型と選ぶ基準は
扱う桁数でいいだろ。
お金だと桁数10桁で足りない事もあるし、そういうときはnumericでいいんじゃね?

俺は、Java上で金額計算するから格納時には桁数roundしてるから
入れ物さえあれば問題ない。

>>590
逆になんでnumericなのか聞けば?
俺は桁数が分かるという利点でnumericにしてるんだと思うがね。
DBのポータビリティを考えて、もう1層上でテーブル設計してるんじゃないか?

594 :NAME IS NULL:2008/05/22(木) 21:10:58 ID:???
>>590

うちも同じようなテーブル設計があったので、直せるところはintにしま
した。物の個数ですらnumericでやってあったから、さらに低レベルかも。
intかbigintの方がコンパクトで高速と思ってます。

595 :590:2008/05/23(金) 12:41:48 ID:???
>>591-594
レスありがとうございます。

とりあえず、DB設計者になぜnumericなのか聞いてみた結果
→「これがいいって聞いたから」

あとは愚痴スレ行きます。。

>俺は、Java上で金額計算するから格納時には桁数roundしてるから
>入れ物さえあれば問題ない。
私も同じようにしようと思います。

ご助言いただき、ありがとうございました。

596 :NAME IS NULL:2008/05/24(土) 07:11:45 ID:???
>>565
ごめん嘘書いちゃった
テーブル指定無しで実行しないとシステムカタログがvacuumされないらしい
http://www.thinkit.co.jp/cert/marugoto/2/1/13/2.htm

597 :NAME IS NULL:2008/05/25(日) 19:07:27 ID:???
>>596
いや、システムカタログ名を指定すればできるだろう。
 VACUUM pg_class;
とか。面倒だから普通は autovacuum に任せるけど。

598 :NAME IS NULL:2008/05/27(火) 14:05:46 ID:ZU6uB09A
結合条件にLIKEなどを使って
あるカラムが別テーブルのカラムを含んでいる行と外部結合ってできないでしょうか?

SELECT o.foo, u.bar FROM hoge o LEFT OUTER JOIN huga u ON o.foo LIKE '%'||u.bar||'%';

じゃだめでした。
なんかうまい方法ないでしょうか?

599 :NAME IS NULL:2008/05/27(火) 14:38:11 ID:???
ONのあとは結合条件、o.foo LIKE '%'||u.bar||'%'はWHERE句に


600 :598:2008/05/27(火) 14:43:16 ID:ZU6uB09A
すいません。
↑のでできてました。

結合するテーブルにINSERTするデータが間違ってるだけでした。
お騒がせしました。

601 :NAME IS NULL:2008/05/29(木) 01:30:00 ID:+Ml1/7K+
日本語データをinsertし、その後格納データ確認のためselectしてみたところ、
以下のようになってしまっておりました。

<BD><BE><CD><E8><CA><FC><C1><F7><A4><B5><A4><EC><A4><BF>
<C8><D6><C1><C8><C5><F9><A4><CF><A1><A2><A5><C6><A1><BC>
<A5><D7><C7><DE><C2><CE><A4><C7><CA><DD><C2><B8><A4><B5>
<A4><EC><A4><C6><A4><A4><A4><BF><A1><A3><A4><DE><A4><BF><A1><A2>

しかしながら、プログラムから同様のSQL文でデータを出力してみたところ、
正常に日本語が表示されました。

本現象に関して何かアドバイス等ございましたらいただけますと幸いです。
宜しくお願いします。

602 :NAME IS NULL:2008/05/29(木) 05:49:30 ID:???
select文を発行したときと
プログラムからのselect時との
client_encodingの違いを意識してるか?



603 :NAME IS NULL:2008/05/29(木) 10:42:05 ID:???
>>601
その<BD><BE><CD>・・・を出力してるのはページャー(more とか lessとか)
そのページャーがその文字コードに対応していない。
ページャーを何とかするか、ページャーにあわせてクライアントエンコードを変更する。

604 :NAME IS NULL:2008/05/29(木) 21:28:20 ID:???
どこかにWinでpgAdminからSlony-Iの使い方解説したサイトはないものか

605 :NAME IS NULL:2008/05/30(金) 10:10:15 ID:???
HELPでいいやん

606 :NAME IS NULL:2008/06/02(月) 17:13:40 ID:???
>>597
いやできない。試しにやってみるとこうなる。
WARNING: skipping "pg_user" --- cannot vacuum indexes, views, or special system tables


autovacuumまかせにできるのは小規模だけだろ。
数GB程度のデータ規模でも、アクセスが少ない時間をねらって
毎日vacuumしないとvacuum時間が長くなって大変。

607 :NAME IS NULL:2008/06/02(月) 17:30:20 ID:???
autovacuumを頻繁に行い、一回あたりの時間を短くする

608 :NAME IS NULL:2008/06/02(月) 17:51:00 ID:???
>>606
pg_userはVIEWですよ。VACUUMできるわけが無いし、する必要も無い。

あと、最近のバージョンだと、vacuum_cost_delayを調整して
vacuum時間を「長くする」側にチューニングしたほうがよい。
レスポンスに影響が無いなら、時間が延びてもデメリットは無い。

「毎日vacuumしないと」も間違い。テーブルによっては、それこそ数分間隔で
VACUUMが必要な場合もあるし、年単位で十分なテーブルもある。
手作業でチューニングするくらいならば、autovacuumのほうが楽だし効率も良い。

VACUUMの運用法は、ここ数年で大きく変わってきているので、
あまり古い考えにこだわり過ぎないことをお勧めする。

609 :NAME IS NULL:2008/06/02(月) 18:21:54 ID:???
特に8.3ではHOTのおかげでvacuumする必要性がだいぶ低くなってきたからねぇ。

610 :NAME IS NULL:2008/06/02(月) 19:24:19 ID:???
8.3て、致命的問題なく動いてる?

611 :NAME IS NULL:2008/06/02(月) 20:04:27 ID:???
>>608
そっか。確かにpg_typeならvacuumできたわ。

>>607
autovacuumって頻度指定できんの?

612 :NAME IS NULL:2008/06/02(月) 20:13:45 ID:???
8.2でautovacuumだけで運用してたらあんまりvacuumされなくて
手動でやるようにしたんだけど。
一日数万件のinsert/deleteがあるのに何日間かvacuumされて
なかったんだよ。んでpgAdminで繋いだらautovacuum設定しろしろうるさい。
してあるのに。

バッチで実行すれば「アクセスが少ない時間帯にvacuumが完了」するように
指定できるし、vacuum実行時間のログもシステム側に残る。

autovacuumが効率よくvacuumかけてくれる事を説明してるURLある?


613 :NAME IS NULL:2008/06/02(月) 21:07:26 ID:???
>>611
autovacuum_naptimeで最小間隔の指定は出来るし、
autovacuum_vacuum_thresholdやらautovacuum_analyze_thresholdやら
いろいろ設定可能

>>612
stats_row_level = onにはなっているよね?

614 :NAME IS NULL:2008/06/02(月) 22:55:08 ID:???
>>612
そのテーブルだけ pg_autovacuum.vac_base_thresh で設定すると良いかも。
別に、バッチVACUUMとautovacuumは排他じゃないから、
むしろ両方とも設定した方が問題が少ないことが多いかな。

615 :NAME IS NULL:2008/06/03(火) 02:16:34 ID:???
今は両方セットしてあるんだけど、とあるテーブルだけ8GBくらいあって
日中にvacuum走ると使い物にならなくなってしまうので、
autovacuumは切ろうかと思ってる。
てか毎日vacuumしてて空き領域が良好な状態だったら
autovacuumは走らないものなの?

616 :NAME IS NULL:2008/06/03(火) 02:59:46 ID:???
>>615
とりあえず、autovacuumが行われるタイミングに関しては
ttp://search.net-newbie.com/pgsql/routine-vacuuming.html
参照。

617 :NAME IS NULL:2008/06/03(火) 04:26:12 ID:???
サンクス
閾値を超えなきゃvacuumされないのね。
とりあえず数万件の削除は日毎バッチで行われていて、
手動バキュームはその直後に行うようになってるから、
よりベターなタイミングっていうのは無いと思うのよ。
とりあえずこのまま行く

618 :NAME IS NULL:2008/06/03(火) 16:19:23 ID:???
クライアントからODBCを使ってサーバのデータベースに繋ごうと思って
ttp://www.advancesoft.co.jp/wiki/?PostgreSQL%B3%B0%C9%F4%C0%DC%C2%B3%CA%FD%CB%A1
のサイトに記載してある通り、pg_hba.confとpostgresql.confを編集して接続を試しても、
Could not connect to the server.
No connection could be made because the target machine activety refused if.
とエラーが出てしまい繋げません。
サーバのlocalhostでの接続は可能でした。

何か原因わかる方いませんでしょうか?
ちなみに環境は
サーバ Windows 2000 Server SP4
クライアント Windows XP SP2
です。

619 :NAME IS NULL:2008/06/03(火) 16:22:44 ID:???
>>618
せめてnetstatの結果ぐらい確認しろよ

620 :NAME IS NULL:2008/06/03(火) 16:53:16 ID:???
>>619
調べてみたら5432のポートが開いてない感じがしたのですが、
その場合どういった対策をすればいいのでしょうか?
postgresql側での設定が必要なのでしょうか?
宜しくお願い致します。

621 :NAME IS NULL:2008/06/03(火) 17:13:06 ID:???
>>620
感じがした、って…オマ…
火壁とかどうなってんの? Windows知らんから、これ以降は誰か頼む。

622 :NAME IS NULL:2008/06/03(火) 17:32:40 ID:???
まず、pgAdminIIIで接続できるか確認してごらん。
つながるならODBCの設定があやしいし、
つながらないならpingとかでネットワークで到達できるかからやってごらん。

623 :NAME IS NULL:2008/06/03(火) 17:34:24 ID:???
>>622
そんなことせんでも telnet で 5432 に繋げればすぐ分かる。

624 :NAME IS NULL:2008/06/03(火) 17:58:57 ID:???
pgAdminIII使ったほうがあとあと役に立つと思ったんだけどな。

625 :NAME IS NULL:2008/06/03(火) 18:57:11 ID:???
>>621-624
ありがとうございます。
pingは無事に到達します。
Windows 2000 Serverにファイアーウォールはないと思うんで特に設定はしていません。
とりあえず今は触れる環境にないので、明日もう少し試してみます。


626 :NAME IS NULL:2008/06/03(火) 19:04:03 ID:???
>>625
お前が"postgresql ポート 設定"でぐぐることすらできないのと、
telnet foobar 5432すらできない知能なのは良くわかったから、
きちんとお勉強してくるまで出入り禁止。

627 :NAME IS NULL:2008/06/03(火) 20:19:57 ID:???
netstatで調べたら5432が開いてないとなったんでしょ?
なのに火壁が!pingが!とか言ってるのはナニ?

pg_hba.confの、この部分もコピペしたとかじゃなくて?
# ローカルのみの設定
host all all 192.168.1.0/24 trust

LANの設定にあわせて記述してますか?
192.168.0.0/24 とか。

628 :NAME IS NULL:2008/06/03(火) 20:26:08 ID:???
>>627
開いてない感じがしただけで
開いてないとは誰も言っていない罠www


>>625
ま、実際にLISTENポートとしてリストされなかったなら、
設定が悪いだけだから、見直して再設定すればいい。


629 :NAME IS NULL:2008/06/03(火) 20:28:37 ID:???
馬鹿は放置しとけよ…

630 :NAME IS NULL:2008/06/03(火) 20:46:21 ID:???
feelingで話を進めた段階でアウトです。

分からない事は分からない。
それを素直に出せないのは、
眼鏡をかけた新人の女の子までしか許されません。

631 :NAME IS NULL:2008/06/03(火) 21:05:04 ID:???
postgres.confのlistenだろ

632 :NAME IS NULL:2008/06/03(火) 21:14:53 ID:???
>>628
しまった!><

633 :NAME IS NULL:2008/06/03(火) 21:21:02 ID:???
>>631
別のポート番号にしたいとき、そこ変えて、service postgresql startとやっても
反映されなくてハマったよー

634 :NAME IS NULL:2008/06/04(水) 03:02:48 ID:???
>>615
>>612の通りだ。
pg_autovacuumテーブルでそのテーブだけ除外してやんな。
で、夜間にvacuumすればよろし。


635 :NAME IS NULL:2008/06/04(水) 03:04:30 ID:???
>>634

ミスったw
>>615 → >>614

吊ってくる

636 :NAME IS NULL:2008/06/04(水) 11:58:40 ID:???
ちょっと質問させてください。
インデックスを複数同時に張るのって、1つ張り×複数とは別のときに効果を発揮する……のでしょうか?
前任者が張りまくっていたものを整理しているのですが、どうなんだろうと思いまして。

1.id, name, dateが指定されたインデックス
2.nameのみが指定されたインデックス
3.nameがインデックス指定+where id=10 と記述

が存在。
1は、その3つを同時にwhere使用する場合にしか使われない? それともidだけをwhere指定する場合でも使ってくれるのでしょうか?
教えて頂ければありがたいです。

637 :NAME IS NULL:2008/06/04(水) 12:02:19 ID:???
aというカラムに「テスト1 テスト2 テスト3」や「テスト1 テスト3」、「テスト2 テスト3」といったようにスペース区切りでキーワードが入っていたとして、条件をテスト1もしくはテスト3に設定し、各種レコードでヒット数を表示するようなことは不可能でしょうか。
本条件の場合、はじめのレコードはヒット数2、2番目は2、3番目は1となれば期待通りとなります。

不可能かとは思いますが、もしもやり方がありましたらご教示いただけますと幸いです。
宜しくお願いいたします。

638 :NAME IS NULL:2008/06/04(水) 13:37:07 ID:???
>>636
8.1だか8,2だかあたりから個別にidだけ使用しても
見るようになった。8からかもしれん。
8のリリースノート見てみて。

一般的にはインデックスを貼った順序通りにWHRE句に書かないと
使ってくれない。その組み合わせでハッシュコード生成するから。
貼ったインデックスより長い条件なら見てくれるけど。

カラムA,B,Cがあって、(A,B)にインデックスが貼ってあったらこうなる。
○WHERE A=x AND B=y
×WHERE B=y AND A=x
○WHERE A=x AND B=y AND C=z

で、新しいバージョンなら個別に貼ってあっても(効率は落ちるだろうけど)
インデックスを見るようになった

639 :NAME IS NULL:2008/06/04(水) 13:44:28 ID:???
>>637
postgresの質問じゃねーけど。
こんな感じでできないかなあ。

SELECT A.ID,
(CASE B.ID WHEN NULL THEN 1 + CASE C.ID WHEN NULL THEN 1)
FROM
テーブル A
LEFT OUTER JOIN テーブル B ON B.ID = A.ID AND B.カラム LIKE '%テスト1%'
LEFT OUTER JOIN テーブル C ON C.ID = A.ID AND C.カラム LIKE '%テスト3%'

SELECTのところはこれじゃ動かないかもだから工夫してみて。
できたらここで報告よろ


640 :NAME IS NULL:2008/06/04(水) 13:54:58 ID:???
ん?
カラムA,B,Cがあって、(A,B)にインデックスが貼ってあったら
○WHERE A=x AND B=y
○WHERE B=y AND A=x
○WHERE A=x AND B=y AND C=z
×WHERE B=y
じゃない?

で、最近は最後のパターンもOKになったんじゃ?





641 :NAME IS NULL:2008/06/04(水) 14:08:09 ID:???
>>637
スペース区切りでキーワード入れちゃってる時点でrdbmsとして終わった感が・・・

create temp table test(id int primary key,a text);
insert into test values(1,'テスト1 テスト2 テスト3');
insert into test values(2,'テスト1 テスト3');
insert into test values(3,'テスト2 テスト3');

select id,count(a)
from (
select id,a from test where a like '%テスト1%'
union all select id,a from test where a like '%テスト3%'
) as test
group by id order by id


642 :NAME IS NULL:2008/06/04(水) 16:22:48 ID:???
>>639-641

ご教示感謝です。

641さんのSQLでうまくいきましたので、こちらを使用させていただきました。

本当にありがとうござした。


643 :NAME IS NULL:2008/06/04(水) 16:56:29 ID:???
分離した上で正規化したほうがいいと思うけど

644 :NAME IS NULL:2008/06/04(水) 17:25:55 ID:???
実際はキーワード羅列なんじゃなくて商品説明文とかなんじゃないの?

645 :sage:2008/06/04(水) 22:28:25 ID:???
>>610

8.3.1、キャスト問題でなかなか8.1からバージョンアップに踏み切れない
状態です。うち、意外に日付や数値の自動キャストに頼ってる場所があった。

もう8.3運用してる人って居るのかなあ?


646 :NAME IS NULL:2008/06/05(木) 03:18:56 ID:???
してるよ
というかDBは8.2だったんだけどjdbcドライバで8.3を
使っちゃって自動キャストで引っかかった。
日付で検索したときに条件に引っかからないだけだったから
大して実害なかったけど。

647 :NAME IS NULL:2008/06/05(木) 08:20:32 ID:???
>> 645
数値はともかく、日付の自動キャストって怖くない?
日付のフォーマット書式って、環境依存だったような。

うちはPreparedStatementを使ってた関係で、
既に型チェックが厳密だったので、特に問題なく8.3に移行できました。

648 :NAME IS NULL:2008/06/05(木) 10:42:17 ID:???
>>636>>640
ご教示ありがとうございました、理解出来ました。
ざっと見8.1からっぽかったですが(これは『個別に貼ってあっても見る』の方かも?)、
ちょっと詳しく調べる時間が無くて提示出来ずに申し訳ないです。

複数インデックスが多い割には何も考えてないSQL文だらけだったので、ちょっと書き換えてきます……。
本当にありがとうございました。

649 :NAME IS NULL:2008/06/05(木) 19:03:47 ID:???
うちもPreparedStatement限定だけど
日付をsetString()してた

650 :NAME IS NULL:2008/06/05(木) 19:07:56 ID:???
>>640
2番目は駄目だと思うな。複数のカラムを組み合わせてハッシュコードを
作るわけだから、順序入れ替えをOKにしたら偉い数のインデックスを
つくらにゃいけなくなる。少なくともOracleは駄目だ。
だからApache TorqueみたいにWHERE句の順序を入れ替えられない
ORMが嫌われてたんだし。

651 :NAME IS NULL:2008/06/05(木) 19:29:59 ID:???
>>650
8.1.11でexplainで確認したら
>>640のパターンは最後のも含めて
全部インデックススキャンになったよ。

652 :640:2008/06/05(木) 19:55:18 ID:???
>>650
手元にある一番古い環境(7.4.19)で試してきた。

create temp table test(a int,b int,c int);
create index i_text_1 on test(a,b,c);
#適当にinsert
SET enable_seqscan TO 'off'

・indexスキャンになる。(INDEX COND: a = 1 and b = 1)
explain select * from test where a = 1 and b = 1;
explain select * from test where b = 1 and a = 1;

・indexスキャンになる。(INDEX COND: a = 1 Filter: C = 1)
・INDEX COND + Filterになる
explain select * from test where c = 1 and a = 1;
explain select * from test where a = 1 and c = 1;

・seq scanになる(Filter: b = 1 and c = 1)
explain select * from test where b = 1 and c = 1;
explain select * from test where c = 1 and b = 1;


653 :NAME IS NULL:2008/06/05(木) 23:26:11 ID:???
>>650
芸術的な妄想しったかw

654 :NAME IS NULL:2008/06/06(金) 05:33:11 ID:???
>>653
昔のOracleがそうだったいうだけで今は違うみたいだね
ここには順序も入れ替えるなと書いてある
ttp://oracle.se-free.com/tuning/B1_index2.html

torqueでwhere句入れ替えられない事に対する文句は昔MLかなんかで見た。


655 :NAME IS NULL:2008/06/06(金) 07:17:44 ID:???
>>654
いやいやいや、そんなこと書いてないw

656 :NAME IS NULL:2008/06/06(金) 07:25:56 ID:???
インデックスを「使うこと」はできたとしても、
その「効率」がだいぶ違うことには注意が必要ですよ。

なんにせよ、Bitmap Index Scan は結構なアドバンテージだと思われ。

657 :NAME IS NULL:2008/06/06(金) 07:54:24 ID:???
>>655
突っかかりたいだけで日本語も読めないのか
「● 複合INDEXは先頭列から指定しないと、INDEXが使用されない」

ttp://www.geocities.jp/mickindex/database/db_optimize.html#LocalLink9
--8.複合インデックスの場合に、列の順粕ヤを間違えている
 col_1, col_2, col_3 に対して複合インデックスが張られているとします。
 その場合、条件指定の順番が重要です。

まあpostgresには関係無い話みたいだし悪かったな

658 :NAME IS NULL:2008/06/06(金) 11:49:08 ID:???
pgpoolを止めずにpgpoolの設定ファイルの値を変更することってできますか?
知っている方いれば、コマンド教えてください!

659 :652:2008/06/06(金) 14:39:23 ID:???
出力される実行計画も同じですし、実行時間もほぼ同じですので
使う事ができるのではなく、オプティマイザが等しく扱ってるように見えます。
(3回ずつ実行してみました)
・explain analyze select * from test where a = 1 and b = 1;
 0.075 ms/0.074 ms/0.074 ms
・explain analyze select * from test where b = 1 and a = 1;
 0.074 ms/0.073 ms/0.073 ms

8.2で652と同じテストを試してきましたが
どの場合もindex ScanになりFilterは発生しませんでした。
また順序を変えたパターンでは実行計画、実行時間に変化はみられませんでした。

oracleはよく分かってないのですが・・・見よう見まねで10gで同様のテストをしましたが
a = 1 and b = 1もb=1 and a=1も同じ実行計画になってるように見えます。
(oracleスレではないので気になるようでしたらそちらで検証してください)


660 :NAME IS NULL:2008/06/06(金) 17:29:56 ID:???
>>658
設定の項目によるんじゃない?
項目によっては要pgpool再起動

661 :NAME IS NULL:2008/06/06(金) 18:23:18 ID:???
indexの順序が関係あるのはOracleのルールベースで
インデックス貼ってた時までだよ。10gでも設定することは
できるけどもうサポートされてない

http://www.shift-the-oracle.com/inside/optimizer.html


662 :NAME IS NULL:2008/06/06(金) 18:30:27 ID:LCupMW8E
どなたか教えてください
トリガで特定のカラムの値が任意の条件を満たす場合のみトリガを発動って出来ますか?
例えば、
status というカラムが 0 という値にupdateされた場合のみトリガ発動 
みたいなことをしたいんです 
可能なら具体的な設定方法をご教授下さい

663 :NAME IS NULL:2008/06/06(金) 18:31:47 ID:???
教授 じゃなく 教示でした。。

664 :NAME IS NULL:2008/06/06(金) 19:04:55 ID:???
>>662
0という値以外にアップデートされたときは何もせずに終わったらよくない?
トリガが実行されることのコストを気にしてるのかな。

665 :NAME IS NULL:2008/06/06(金) 19:54:05 ID:???
>>647

たしかにまずいですよね。substr(日付)とやってる処理があって、いま
手直ししてます。ぜんぜん意識してなかったです。。


666 :NAME IS NULL:2008/06/07(土) 02:50:25 ID:???
>>659
その程度の最適化は今時どんなDBMSでもやってくれるよ。
同じで当然。

667 :NAME IS NULL:2008/06/07(土) 03:15:17 ID:???
>>666
流れが読めない人だなあ

668 :NAME IS NULL:2008/06/11(水) 15:56:27 ID:???
select 文を書く時みなさんはどちらを使いますか?
またその理由を教えてもらえると助かります。
ちなみに自分は@派です。

@select column from table where integer = 1;
Aselect column from table where integer = '1';


669 :NAME IS NULL:2008/06/11(水) 16:45:08 ID:???
スクリプトの人はわからんが、Cやってる人なら文字列と数値を
ごっちゃにするのは嫌うんじゃ

670 :NAME IS NULL:2008/06/11(水) 17:02:46 ID:???
>>668
明確に違うものをなぜ同一視する。
文字列である数字と、数値を表す数字では、意味が違う。

671 :NAME IS NULL:2008/06/11(水) 18:10:46 ID:???
>>668
A 昔はこれしかなかった。

672 :NAME IS NULL:2008/06/11(水) 19:21:42 ID:???
そういえば、7.4 の時代には、@で int8 を検索してインデックスが使われない〜
ってのは頻出だったな。今は大丈夫だが。

ちなみに '1' だけでは、まだ文字列ではない (unknown) 。
何かしらの型への変換が要求された時点でパースされる。

=# select foo(1);
ERROR: function foo(integer) does not exist
=# select foo('1');
ERROR: function foo(unknown) does not exist


673 :668:2008/06/11(水) 22:59:50 ID:???
いろいろレスありがとうございます。
自分は>>669さんと同意見なんですが、
絶対 '1' にしろという人が身近に入るもので気になりました。

あと>>671さんの意見でなんとなく理由がわかりました。


674 :NAME IS NULL:2008/06/12(木) 06:06:46 ID:???
暗黙の型変換が行われると速度が遅くなるから
元のカラムの型がintなら1を使うべきだと思ってたんだけど
そう単純な話でもないんだな

675 :NAME IS NULL:2008/06/12(木) 07:01:53 ID:???
リテラルであれば別に型変換があっても実行速度は変わらんしな。

676 :NAME IS NULL:2008/06/12(木) 07:56:21 ID:???
>>671
私はORACLEのバージョン3から使ってますが、当時から
数値はシングルクォーツなしで参照できたが・・・


677 :NAME IS NULL:2008/06/12(木) 10:15:58 ID:???
>>676
私もその少し前からだと思う。マニュアルでは
WHERE DEPTNO = 30  であるのに 処理系では
WHERE DEPNTO = '30' でないとエラーになった記憶がある。
それで '30' とする習慣になってしまった。
もしかして、私の勘違いだったのかな。

678 :NAME IS NULL:2008/06/12(木) 13:21:33 ID:dWhU52qw
PostgreSQL 8.3.3, 8.2.9, 8.1.13, 8.0.17, 7.4.21

679 :NAME IS NULL:2008/06/12(木) 15:23:39 ID:eu0D2QJA
DB2台で冗長構成にしたいのだが、
pg_poolはシーケンスの整合性を取る場合にはテーブルロックが必要なのね。
テーブルロックしない方法は何か無いかしら?
Slony-IIとかpgClusterも同じでしょうか?

難しいなら障害時にDB1からDB2に自動的に切り替わらるといった障害耐性が
無くてもよいかな。単純にレプリケーションが取れていれば。

680 :NAME IS NULL:2008/06/12(木) 19:17:16 ID:???
>>677
そのカラムがvarcharで定義されてたんじゃなくて?

681 :NAME IS NULL:2008/06/12(木) 21:59:56 ID:???
>>679
drbdとか使ってミラーリングしとくとか
自動で切り替わらなくていいならPITRでリモートにバックアップとか



682 :NAME IS NULL:2008/06/13(金) 05:58:44 ID:???
>>679
Slony-I ならテーブルロックしない。(-IIはリリースされてないよ)
pgCluster は、そもそも更新性能が 1/10 になるという噂もあるので微妙。
冗長化だけで良いなら、>>681のとおり、warm-standbyかDRBDが良いかも。

683 :NAME IS NULL:2008/06/13(金) 15:17:28 ID:???
ここで愚痴ってもしょうがないけど・・・

signed/unsigned修飾子とtinyint型がほしいorz

今時誤差の範囲かもしれないけど貧乏症なので
smallintだと入らないけどunsigned smallintなら入りきる時とか
tinyintで十分な時とか悔しくてしょうがないんだ


684 :NAME IS NULL:2008/06/13(金) 18:17:27 ID:???
>>683
DBの実装はよくわからないけどC言語の時は、
shortで宣言してもCPU内ではintで確保して半分未使用になるだけなので
実は速度はintの方が早いっていうのがあったよ。

大量のデータを構造体にしてネットワークでやりとりするときは
packed宣言すればデータ量を節約することはできたけど。
構造体へのポインタ(アドレス)からsizeof(構造体)分をbyte[]にキャスト
して使うような太古の作り方の話だけどね。

685 :NAME IS NULL:2008/06/13(金) 19:27:54 ID:???
今でも一番パフォーマンスが出るのはintだと書かれているよ

686 :NAME IS NULL:2008/06/13(金) 19:30:08 ID:???
http://www.postgresql.jp/document/pg831doc/html/datatype-numeric.html#DATATYPE-INT
参考までに。

687 :NAME IS NULL:2008/06/13(金) 19:39:55 ID:???
>>684
C言語は、intがその処理系で一番パフォーマンスが出るように、と選ばれます
なのでintが速いのは当然です。

688 :NAME IS NULL:2008/06/13(金) 20:11:32 ID:???
>>683
さぁ、ユーザ定義型を自作するんだ!

689 :NAME IS NULL:2008/06/13(金) 23:15:36 ID:???
>>684
DBはそのネットワークと似たようなもんだよ。結局ディスクIOが最大のネックだから。
何億レコードにもなるようなテーブルは1byteでも減らしたくなるのが人情。

690 :NAME IS NULL:2008/06/14(土) 00:11:27 ID:???
>>686
サイズと性能の釣り合いがとれてる(=コストパフォーマンスがいい?)のはintだと
書かれているけど、小さいサイズで構わないときにsmallintよりintの方が
速いとはかかれてないね。

>>689
ごもっともで

691 :NAME IS NULL:2008/06/14(土) 00:18:06 ID:???
みんなポスグレのレプリケーション何使ってる?

692 :NAME IS NULL:2008/06/14(土) 00:49:03 ID:???
レプリケが必要なプロジェクトではポスグレなんか使わない。
1日1,2回のpg_dump

693 :NAME IS NULL:2008/06/14(土) 20:34:22 ID:???
普通はSlony、同期が必要ならpgpool、
バックアップ用ならwarm-standbyで鉄板じゃないの。

694 :NAME IS NULL:2008/06/15(日) 00:45:18 ID:???
>>690
なるほどなるほど。確かに。
では、たとえばsmallintのほうがintよりも速い場合、以下のような記述をするでしょうか?
> smallint型は一般的にディスク容量に制限が付いている場合にのみ使用します。
                                       ~~~~
どうせならこう書きそうじゃないですか?
> smallint型に収まるデータを扱う場合はsmallintを使用することを推奨します。
> なぜならずっと速いからです。

あえて先の記述をするということは対して速度に差がないのであろうと想像します。
実際に測定するのが手っ取り早いんですけど、ドキュメントから読み取れることも多いと思います。

695 :NAME IS NULL:2008/06/15(日) 01:13:31 ID:???
キモイキモイナニモカモキモイ

696 :NAME IS NULL:2008/06/15(日) 01:48:21 ID:???
>>694
状況によるだろ。
100GBのテーブルと200GBのテーブルのfull scanを比較したら小さい方が速いだろうし。

697 :NAME IS NULL:2008/06/15(日) 09:11:54 ID:???
>>691

うちはpgpool II 使ってます。ハード障害対策で使ってるんだけど、
意外にハード障害が起こらなくて、今のトコ手間だけ2倍以上な印象。
2重化してるせいで、大量更新集中時の読み出し処理とかは、片側から
読むようにしたりとか、変なコツが必要だったりする。


698 :NAME IS NULL:2008/06/15(日) 13:40:18 ID:???
>>693
>>697
やっぱりpgpoolが多いのですねぇ。。。うちはPGclusterのロードバランシング機能はずした状態で使ってんだけど
ほかにそういう人いないかな。選んだ理由はデータ復旧がコマンド一発で楽だからなんだけど。

699 :NAME IS NULL:2008/06/15(日) 23:02:13 ID:???
今PC用でpostgresでデータベースのみ使っています。
今度携帯用データベース作ろうとしたとき
一緒にするか分けるかどっちがいいんですかね…?
mysqlとpostgresを併用するのは速度的にはどうなんでしょ?

700 :NAME IS NULL:2008/06/16(月) 02:08:25 ID:UXZw8p6G
質問させてください

vistaにposgreをインストールできたのですが、postgresとつけたアカウントのパスワードで、データベースpostgresにアクセスしようとすると
フリーズしてしまいます。
どうすればvistaでフリーズしないで使えるようになるのでしょうか?

701 :NAME IS NULL:2008/06/16(月) 02:36:58 ID:???
>>700
フリーズってPC(OS)丸ごと? クライアントアプリだけ?
アクセスしようとしたクライアントはナニ?
postgres以外のアカウントだとどぉう?

っていうか、posgreってなんだよ。

702 :NAME IS NULL:2008/06/16(月) 09:29:14 ID:???
>>699
別にPostgreSQLで困りはしないだろ。


703 :NAME IS NULL:2008/06/16(月) 11:34:23 ID:???
>>699
どっちでもいいので、DBは統一しておいた方が楽。
特にこだわりがなければPostgreSQLでいいでしょう。

704 :NAME IS NULL:2008/06/16(月) 15:32:22 ID:???
http://www.postgresql.jp/落ちてる?

705 :NAME IS NULL:2008/06/16(月) 16:38:53 ID:???
>>704
そうみたい

706 :NAME IS NULL:2008/06/16(月) 16:40:42 ID:???
>>699
併用しても問題ないけど、管理の手間を考えたらposgres一本の方がいいよ。
キャッシュの割り当てとかも一括だし。運用に携わる人はpostgresもmysqlも
どっちもプロフェッショナルなの?両方混ぜると似たようなコマンドで混乱すると思うんだけど。

あとマスタとか共通利用できないの?できるんだったらマスタテーブル一個の方が
更新も楽だしいいと思うけど。ものすごい負荷の高いシステムで将来的に
DBをわける可能性が大きいなら、今からインスタンスを分けておく意味も
あるかもしれない。

707 :NAME IS NULL:2008/06/16(月) 23:12:40 ID:???
もし分けるとしても同じDBMSのほうがよさげに思う。
同じシステムのPC版、携帯版という違いであれば同じDBMSにしといたほうがいいよ。

708 :700:2008/06/16(月) 23:47:37 ID:???
>>701
DOSからアクセスしたのですが、passを入力してenter押すとOSごとフリーズしてしまいます。

709 :NAME IS NULL:2008/06/16(月) 23:49:20 ID:???
>>708
ローカルマシンのPostgreSQLインスタンスにpsqlで接続しようとしたらOSごとフリーズってことですか?

710 :699:2008/06/16(月) 23:56:17 ID:???
>>702、703、706、707
みなさん、ありがとうございます。
postgresで統一したいと思います。

PCと携帯で違うデータを見せたいのですが
マスタテーブルも一つにした方が良さそうですね・・・。
ありがとうございました。

711 :NAME IS NULL:2008/06/17(火) 10:26:27 ID:???
統一にしても、DBクラスタを別にしてPostgreSQLを複数起動するとか、
DBを別にするとか、スキーマでわけるか、テーブルで分けるか、キーで分けるか、

712 :700:2008/06/17(火) 17:27:59 ID:???
>>709
そうです、ネットで調べた通りにやったのですが無理でした。

713 :NAME IS NULL:2008/06/17(火) 17:47:13 ID:???
>>712
まずメモリをチェックしなさい。
次にHDDをチェックしなさい。

Linux(Unix)ならこんな事で落ちない。
うんともすんとも言わない。メッセージが出ない。
保護違反とかのエラーは全てメモリエラーと思っていい。

714 :NAME IS NULL:2008/06/17(火) 18:20:27 ID:???
メモリエラーの結果、誤動作して保護違反ということはあるかもしれないが
保護違反とメモリエラーとは直接の関係は無い。

715 :NAME IS NULL:2008/06/17(火) 18:25:12 ID:???
保護違反じゃなくて、理由のわからないフリーズはハードを疑ったほうがいいけどな。
フリーズってのが全体が止まるのならな。

716 :NAME IS NULL:2008/06/17(火) 19:18:07 ID:???
ハードだろうね。
保護違反ならメッセージ出るか再起動するかする

717 :700:2008/06/18(水) 00:44:28 ID:???
ということは、自分のパソコンを修理に出すべきなんでしょうか?
普通に使っている分には、まずフリーズしないのですが・・・SP1入れようとするとフリーズしますが・・・。

718 :NAME IS NULL:2008/06/18(水) 01:32:15 ID:???
ノートで熱暴走してるとか

ないか

719 :NAME IS NULL:2008/06/18(水) 04:34:25 ID:???
>>717
だめじゃん

720 :NAME IS NULL:2008/06/18(水) 10:21:41 ID:???
アンチウィルスソフトで引っかかってUAEの警告だそうとしてるだけとか

ないか

pgAdminではつなげないの?

721 :NAME IS NULL:2008/06/19(木) 00:15:18 ID:???
sp1入れてフリーズって普通じゃないよな。
pc新規購入をお勧めする。

722 :NAME IS NULL:2008/06/19(木) 00:24:28 ID:???
PC買い替える前にOS再インストールだな。

723 :NAME IS NULL:2008/06/19(木) 01:34:49 ID:???
の前にH/Wいろいろチェック

724 :NAME IS NULL:2008/06/20(金) 11:25:00 ID:???
Explaining Explain日本語版ドラフト ? NPO法人 日本PostgreSQLユーザ会
http://www.postgresql.jp/blog/56
にある Explaining Explain の日本語版読んでみたいんですが、
パーマリンクの変更があった影響なのか
単にもうファイルがないのか読めないでおります。
どなたかファイル持ってる方いらっしゃればどこかにあげていただけないでしょうか?
JPUG公式ぽいんですが、コメントのSPAM荒れっぷりを見てもメンテされてない可能性があるので
こちらにきてみました。

コリコリにDBチューニングしたいわけではなくて、SQLかく時にある
ちょっとした迷い(結果同じだけどどっちの書き方がいいかな?)
をクリアする助けになればなぁと思ってる感じです。


725 :NAME IS NULL:2008/06/20(金) 12:05:19 ID:???
>>724
困った時の、Web Archive
http://web.archive.org/web/20060429195622/http://blog.postgresql.jp/images/Explaining_Explain_ja.pdf


726 :724:2008/06/20(金) 12:59:02 ID:???
ぐぁ・・・基本的なことが抜けておりました。
大感謝です!

727 :NAME IS NULL:2008/06/28(土) 23:16:56 ID:???
すみません
質問させて下さい。

PostgreSQL Ver 8.3
WindowsServer2003
でDBを運用しているのですが、
現在dataフォルダが初期インストールパスのままになっております。
別ドライブにdataフォルダを移動しようと試みて、
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pgsql-8.3\ImagePath
を変更してみたのですが、
変更先がCドライブ以下なら変更可
他のドライブは変更不可(サービスが起動しない)
となってしまいます。

この場合、dataフォルダを退避して、PostgreSQLの再インストール
しか方法は無いのでしょうか?
何とかdataフォルダの移動だけで済ませたいと考えております。

アドバイスを宜しくお願いします。

728 :NAME IS NULL:2008/06/28(土) 23:32:34 ID:???
上げてみました

729 :NAME IS NULL:2008/06/28(土) 23:45:40 ID:???
うちのWinXPでは実行ファイルはC:にインストールしてあって、
-Dで指定するデータ領域は別のドライブにしているけど、普通に動いてる。

730 :NAME IS NULL:2008/06/28(土) 23:55:33 ID:???
>>729さん
ありがとうございます。

多分initdb.exeで -D 以降に移動させたいファイルパスを指定
してあげればいいのかなと思うのですが、initdb.exeの使い方が
いまいちわかりません・・・。

新規にデータ領域を作成して、そこに既存のdataフォルダをコピー
するような感じでいけるんでしょうか?

initdb.exeはコマンドプロンプトで実行するのでしょうか?

もしわかれば教えてください。
宜しくお願い致します。

731 :NAME IS NULL:2008/06/29(日) 00:06:36 ID:???
既存のデータ領域があるなら丸ごとコピーして-Dでそっちを指すようにすれば動くんじゃないかな。
initdb はコマンドプロンプトで --help とかつけて動かせば説明が出るけど、
>>1のドキュメントを読んだ方が良いかも。

732 :NAME IS NULL:2008/06/29(日) 01:13:30 ID:???
>>731
アドバイスありがとうございます。

取り合えず調べて、空の別ドライブのdataフォルダにinitdbの実行し
成功するまでは出来ました。

その後、新規dataフォルダを既存のdataフォルダに上書きして、
サービスの実行・・・・・・起動不可

再度、空のdataフォルダを作成して、initdbを実行。
今度はそのままサービスの起動・・・・・・起動不可

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pgsql-8.3\ImagePath
の値はinitdbの指定パスと同じにしているのですが、他に設定
が足らないのでしょうか?


733 :NAME IS NULL:2008/06/29(日) 01:34:59 ID:???
>>732
コントロールパネル -> コンピュータの管理 -> サービス を開いて
PostgreSQLのプロパティを見て、[全般]タブの「実行ファイルパス」が
レジストリと同じ値になっているか確認して味噌。

っていうか、レジストリを直接弄るってはじめて知った。
scコマンドを使うものばかりだと...。

734 :NAME IS NULL:2008/06/29(日) 01:37:19 ID:???
システムのログでも見れば。

735 :NAME IS NULL:2008/06/29(日) 02:05:45 ID:Kc/12zlO
>>733
>>734
ありがとうございます。

>レジストリと同じ値になっているか確認して味噌。
ここは同じになっております。
多分、レジストリの値を参照して、ここに表示しているようですね。

>システムのログでも見れば。
今見てみました。
postgres cannot access the server configuration file "F:/data/postgresql.conf": No such file or directory

とのエラーメッセージを発見しましたが、該当の
F:\data\postgresql.confは存在します。

なぜでしょう?


736 :NAME IS NULL:2008/06/29(日) 02:28:40 ID:???
>>735
元Unix系でWindowsに移植されると、あるのにNo such file... って出て悩ませるときがあるよねぇ。
ユーザpostgresに読み取りアクセス権限が設定されていないとか。
そんときゃpostgresql.confだけじゃなくて、/dateディレクトリ下の全てのファイルとディレクトリを
設定し直さなきゃだが?

737 :NAME IS NULL:2008/06/29(日) 11:49:56 ID:???
psql (PostgreSQL) 8.2.4 を使ってますが、バックアップとリストアをしようとしています。
pg_dumpallでファイルにバックアップした後リストアすると文字化けが発生してしまいます。
登録データーがSJISなのですが、OSはUTF-8 CJKになってる為と思われますが文字化けを回避する方法はありますでしょうか。
また、上記状態でpg_dumpallしてあるファイルを文字化け無しにリストアする事は出来ないでしょうか。
宜しくおねがいします。

738 :NAME IS NULL:2008/06/29(日) 11:55:18 ID:???
つ nkf

バックアップ前・後のDBの文字コードは同じ?
FTPとかを利用してファイル移動とかする際に
文字化けが入ってしまう可能性は無い?
使用しているOSは?

もうちょっと情報プリーズ

739 :737:2008/06/29(日) 12:21:50 ID:???
>>738

早速のご回答、ありがとうございます。
バックアップ前・後のDBの文字コードは同じです。
postgresはfedora上で動いており、XPからwinSCPとputtyを使ってアクセスしてますが
バックアップしておいた時点のDBを再現したいので最悪はputtyでログインして
fedoraのディスクにそのままバックアップとリストアが出来れば良いです。
出来ればwinscpでローカルのXPにバックアップ出来れば嬉しいですが…

nkf、ググって見ました。pg_dumpallしてしまったファイルに適用しても元に戻せるのでしょうか。ちょっとやってみます。

740 :NAME IS NULL:2008/06/29(日) 12:24:11 ID:???
>>738
>FTPとかを利用してファイル移動とかする際に
>文字化けが入ってしまう可能性は無い?

記憶が曖昧なのですが、fedora上でputtyでログインし
バックアップとリストアしても文字化けした様に思います。

741 :NAME IS NULL:2008/06/29(日) 12:34:07 ID:???
× 記憶が曖昧なのですが、fedora上でputtyでログインし
○ 記憶が曖昧なのですが、fedoraにputtyでログインし

742 :NAME IS NULL:2008/06/29(日) 13:06:59 ID:???
>> 737
そもそもDB作るときに文字コード何にした?

$ psql -U postgres -l
List of databases
Name | Owner | Encoding
------------------+-----------+----------
***** | ******** | UTF8

この一番右のEncodingの値


743 :NAME IS NULL:2008/06/29(日) 13:21:10 ID:???
>>742

-bash-3.2$ psql -U postgres -l
List of databases
Name | Owner | Encoding
-----------+----------+-----------
postgres | postgres | UTF8
template0 | postgres | UTF8
template1 | postgres | UTF8
test | postgres | EUC_JP
test1 | postgres | SQL_ASCII
(5 rows)

となってます。test1が目的のDBなのでSQL_ASCIIで良いでしょうか。

744 :NAME IS NULL:2008/06/29(日) 13:42:39 ID:???
>>743
テストしてみた

test1が元データだよな?

## 吸出し部分
# DB作成
createdb -U postgres -E SQL_ASCII test2

# test2にSJISデータを流し込む(手動)

# データ吸出し
pg_dump -U postgres test2 > test2.sql

# SJISからUTFに変更
cat test2.sql |nkf --ic=sjis -w > test2.sql.utf

# ここでFedora上で読めるようにUTFに変換されている
# winscpでwindowsに転送してみた
test2.sql => SJIS
test2.sql.utf => UTF8
の文字コードであることを確認

# 戻すテスト
createdb -U postgres -E SQL_ASCII test4
cat test2.sql.utf |nkf -s |psql -U postgres test4

これで無事に戻せた。

特に問題なさそうだが、何処でダメなんだ?

745 :NAME IS NULL:2008/06/29(日) 14:38:36 ID:???
>>744
実験までして頂いてお手数掛けます。

>test1が元データだよな?
そうです。pg_dumpは部分的ににかバックアップしない様なので使ったことが無いのですが

pg_dumpall > backup.sql
とした時にbackup.sqlが既に壊れているのでは無いかと考えていて
今、実験中なのですが自信が無いです。

単純に
pg_dumpall > backup.sql
psql -f backup.sql
とした時に標準出力(linuxのUTF)で化ける事って無いのでしょうか。
backup.sqlはUTFに変換されてしまいますよね。
それとも、実験して頂いた手順に
># SJISからUTFに変更
とあるのでSJISのままなのでしょうか。

746 :NAME IS NULL:2008/06/29(日) 14:52:45 ID:???
>>745
とりあえずbackup.sqlの文字コードを調べてみ。

こんなかんじで。

$ nkf --guess test2.sql
Shift_JIS
$ nkf --guess test2.sql.utf
UTF-8

ここまで書いて思ったんだが

test | postgres | EUC_JP
test1 | postgres | SQL_ASCII

ってことはEUC_JPのやつとSJISのデータを混ぜて出力してる?

747 :NAME IS NULL:2008/06/29(日) 16:55:09 ID:???
>>746
やってみました

-bash-3.2$ nkf --guess backup.sql
BINARY

でした。

ちなみにbackup.sqlの先頭の方で

SET client_encoding = 'UTF8';
SET standard_conforming_strings = off;
SET escape_string_warning = 'off';
 | |
REVOKE ALL ON DATABASE template1 FROM PUBLIC;
REVOKE ALL ON DATABASE template1 FROM postgres;
GRANT ALL ON DATABASE template1 TO postgres;
DROP DATABASE test;
CREATE DATABASE test WITH TEMPLATE = template0 OWNER = postgres ENCODING = 'EUC_JP';
DROP DATABASE test1;
CREATE DATABASE test1 WITH TEMPLATE = template0 OWNER = postgres ENCODING = 'SQL_ASCII';

となっていてエラーも出ていない様なのですが、多種類の文字コードだと出力出来ないのでしょうか。



backup.sqlの容量が900Mバイトもある為かサーバの反応が遅すぎるので、テスト用のサーバーを買ってこようと思います。


748 :NAME IS NULL:2008/06/29(日) 17:45:07 ID:???
>>747
>多種類の文字コードだと出力出来ないのでしょうか。
DBごとにdumpしてみたらどうなのさ? もうちょと自分で思考錯誤しる。

749 :NAME IS NULL:2008/06/29(日) 19:03:19 ID:???
もしかして: 試行錯誤

750 :737:2008/06/30(月) 07:50:38 ID:???
>>748

DB毎にdumpしてみましたが文字化けが発生している様でした。
別サーバーを立てて文字化け部分を切り出そうとしている所ですが
昨日の初書き込みから、お蔭様でだいぶ進展した感じです。
暫く自分でやって見てまた判らない事がありましたら質問させて頂きます。
本当にありがとうございました。

751 :NAME IS NULL:2008/06/30(月) 16:37:15 ID:???
環境変数のPGCLIENTENCODINGとか?

752 :NAME IS NULL:2008/06/30(月) 16:40:40 ID:???
DB毎に文字化けってどういうこと?
例えばEUC_JPで出したものをEUC_JPとして見ようとしても化けてるの?

文字化けしてると勘違いしてるだけじゃね?


753 :NAME IS NULL:2008/06/30(月) 18:37:06 ID:???
DBをASCIIでつくっちゃったんならクライアントの
文字列をそのままバイト配列として格納してくれるんだっけ?

新しいDBをUTFで作ってプログラム組んでSELECT->INSERTしたほうが
早そうだけなあ


754 :NAME IS NULL:2008/06/30(月) 23:38:49 ID:???
現在レンタルサーバを借りているのですが、データベースのバックアップをしようと思い、pg_dumpをした所「WARNING: ignoring unconvertible UTF-8 character」と言ったメッセージが表示されました。
ただ一応ダンプデータは作られたので、そのデータを元に復旧を試みた所、一部データが欠落していました。

ググッてみて文字変換の問題のような気がしたのですが、ユーザーレベルで解決する方法が分かりませんでした。
ttp://www.google.com/search?num=50&hl=ja&lr=lang_ja&q=WARNING:+ignoring+unconvertible+UTF-8+character&revid=994610375&sa=X&oi=revisions_inline&resnum=0&ct=broad-revision&cd=1

その為何か良い手ががございましたら、アドバイスをいただければと思います。
よろしくお願いします。

755 :NAME IS NULL:2008/07/01(火) 02:01:50 ID:???
>>754
DBがUTF-8でシェルのLANGがUTF-8じゃないとかじゃないの?
繰り返しになるけど、
環境変数のPGCLIENTENCODINGとか?

756 :NAME IS NULL:2008/07/01(火) 15:37:39 ID:???
PostgreSQLって基幹業務でも安心して使えますか?

757 :NAME IS NULL:2008/07/01(火) 16:10:24 ID:???
>>756
管理者が詳しければ安心
管理者が詳しくなければどのRDBMS使っても安心できない。

758 :NAME IS NULL:2008/07/01(火) 16:14:23 ID:???
DB本体はともかく、基幹業務となるとバックアップとレプリケーションかなぁ。
一番の問題はPostgreSQLを扱えるSIの質と数だろうけど。

759 :NAME IS NULL:2008/07/01(火) 16:30:12 ID:???
1万ユーザーで同時使用は1000人くらいですが
パフォーマンス的には問題ないでしょうか?

760 :NAME IS NULL:2008/07/01(火) 16:37:14 ID:???
使用状況や環境にもよるでしょ。

761 :NAME IS NULL:2008/07/01(火) 16:43:03 ID:???
具体的なトランザクション数とまでは言わないけれど、一口に同時使用が
1000人といっても、それはフロント部分の作りに大きく依存するでそ。
それだけじゃなんとも言えない罠。ただ、今現在そのシステムがOracle等で
動いているのなら、パフォーマンス的にはPostgreSQLでも動くはず
というのはいえる。

762 :NAME IS NULL:2008/07/01(火) 23:30:29 ID:???
>>755
ありがとうございます。
確認した所下記のようになっておりましたorz。
LANG=ja_JP.eucJP
PGCLIENTENCODING=EUC_JP

現時点でレンタルサーバの設定は触れないので、
自分で似たような環境を作り試してみた所、
UTFからEUCに変換できない文字(?など)があると現象が発生するような感じでした。

多分データベースがUTF-8なのに対し、PGCLIENTENCODINGがEUC_JPの為、
pg_dump時にEUC_JPにコンバートしてしまい、EUCに変換できない箇所でWarningが出ているのかなと思いました。
なおLANGは無関係そうな感じでした。

その為、PGCLIENTENCODINGの設定を変更してもらう方向で検討してみたいと思います。
どうもありがとうございました。

763 :NAME IS NULL:2008/07/01(火) 23:34:10 ID:???
>>762の上から8行目は文字コード0xE28094のUTFの文字を貼り付けたのですが、文字化けしてしまいました。
多分pg_dumpでも同じようなことがおきてWARNING表示になったのだと思います。

764 :NAME IS NULL:2008/07/01(火) 23:53:51 ID:???
>>762
自分の環境変数は自分で変えられるよ
export PGCLIENTENCODING=UTF-8
ってやってからpg_dumpしよう

765 :NAME IS NULL:2008/07/01(火) 23:58:16 ID:???
連投ごめんです。
記憶違いでなければ、PGCLIENTENCODINGが設定されていない場合はLANGが使用されたと思うよ。

んで、ダンプファイルを突っ込むときにエンコード周りのエラーが出た場合なんだけど、
ダンプファイルの中の set client_encoding という行がある場合はそれが
優先されているので、そこがおかしくないかチェックしてみるとよいです。

766 :NAME IS NULL:2008/07/02(水) 00:15:01 ID:???
>>764
レスどうもです。
一応自分で構築したサーバーで>>764の記述と
export PGCLIENTENCODING=EUC_JP
でのpg_dumpの出力結果を元に>>762のような感じかなと推測しました。

実際に使用しているレンタルサーバーの方は、
自分の判断だけでは手がつけられないため、試してないですが。

>>765
私の構築したサーバーの設定は下記ですが、問題なかったのはLANGにUTF-8を指定してたからということですね。
LANG=ja_JP.UTF-8
PGCLIENTENCODINGはなし

危うく、PGCLIENTENCODINGの設定を無くすだけで終えるところでした。
データベースは複数ありますがどれもUTF-8なので、PGCLIENTENCODINGをUTF-8にする方向で対応したいと思います。

後、手元に問題のダンプデータがないので、明日Warningのでる場合と出ない場合のset client_encodingの記述をチェックしてみます。
どうもありがとうございました。

767 :NAME IS NULL:2008/07/02(水) 09:25:32 ID:???
pg_dumpに-eって無かったっけ?

768 :NAME IS NULL:2008/07/02(水) 10:01:57 ID:???
-E または, --encoding= でしょ、あるよ。

769 :737:2008/07/02(水) 11:28:22 ID:???
>>751
今回は関係なかった様です。ありがとうございました。

>>752
EUC_JPのDBは化けてませんでした。
と言うか、SQL_ASCIIのDBを削除する為に仮に作っただけだったので、データーが殆ど入ってなかったと言うのもありますが。


追伸
SJISの文字化けで質問していた者です。他の業務が入ってしまい追試が遅くなりました。
色々やってみましたが、DBから携帯からのメールのみ削除してバックアップした所文字化けがなくなりました。
携帯の特殊文字に関連しているのかも知れません。とりあえずプログラマにその旨を伝え、対応してもらう事になりました。
時間が取れたらこちらでも詳しく調べようと思います。
ご教示頂いた皆様、本当にありがとうございました。

追伸2
4GのメモリとQuadのマザー買っちゃいました。素人が試行錯誤するには反応が早くて良いですね。

770 :NAME IS NULL:2008/07/02(水) 21:56:28 ID:???
>>765
set client_encodingチェックしました。
すべてのダンプがEUCでしたorz
どうもありがとうございました。

それと、私が試した限りではPGCLIENTENCODINGが設定されていない場合、
LANGではなく、データベースのEncodingが使用されているようでした。
その為、下記のaaaaというデータベースのダンプはEUC_JPで作られ、
bbbbというデータベースはUNICODEで作られていました。

 List of databases
Name|Owner|Encoding
-----+-----+--------
aaaa |ccccc |EUC_JP
bbbb |ddddd |UNICODE


>>767>>768
使用しているバージョンが7.4.19なのですが、このバージョンでは-Eと--encoding=はないようです
(pg_dump --helpで調べましたが、そのオプションは存在せず、試してみてもエラーになりました)。
出来れば既存の環境には手を加えたくないので、PGCLIENTENCODINGには手をつけず、
pg_dump -Eで対応できれば良かったのですが。
何か良い案があるようでしたらアドバイスいただければと思います。
今はまだPGCLIENTENCODINGを変更すると、既存の環境に悪影響が出ないか検証できていない為、
変更できていないので。

なおpg_dumpのマニュアルは下記を参考にしました。
ttp://www.postgresql.jp/document/pg812doc/html/app-pgdump.html
ttp://www.postgresql.jp/document/pg746doc/html/app-pgdump.html

771 :NAME IS NULL:2008/07/02(水) 23:37:35 ID:???
>>765
PGCLIENTENCODINGが設定されてない場合の補足ですが、
下記のサイトに以下の記載がありました。

> -E encoding
> --encoding=encoding
> 指定した文字セット符号化方式でダンプを作成します。デフォルトでは、ダンプはデータベースの符号化方式で作成されます
> (PGCLIENTENCODING環境変数を好みのダンプ時の符号化方式に設定することで、同じ結果を得ることができます)。
ttp://www.postgresql.jp/document/pg812doc/html/app-pgdump.html

この文章の「デフォルトでは、ダンプはデータベースの符号化方式で作成されます」というのが、
>>770のEncodingの部分を指していると思われます。

772 :NAME IS NULL:2008/07/03(木) 02:08:24 ID:???
テーブルに登録している「folderpath」を
SQLのWHERE句にて
Like検索したいのですが、
以下結果となりました。


1. folderPath = "c:\\test" OK (データ取得成功)参考
2. folderPath like "c:%" OK
3. folderPath like "c:\%" OK
4. folderPath like "c:\\%" NG (取得データ0件)
5. folderPath like "c:\t%" NG
6. folderPath like "c:\\t%" NG


\が入っているフォルダパスを
検索する良い方法はないですか。

よろしくお願いします。


773 :NAME IS NULL:2008/07/03(木) 03:31:45 ID:???
>>772
フロントエンド(psqlなりプログラミング言語なり)がエスケープする分とlikeがエスケープする分が必要。

folderPath like 'c:\\\\%'

774 :NAME IS NULL:2008/07/03(木) 09:53:15 ID:???
c:\% がOKなのは、 c:\% → c:% → c:% だからだな。

775 :NAME IS NULL:2008/07/04(金) 14:49:20 ID:gyCCSjbu
MYSQLからPostgreSQLに乗り換えたいと思いインストールしてみたんですが
phppgadminから起動が出来ません

環境は
apache2.2/PHP5/PostgreSQL8/WindowsXP
php.iniの php_pgsql.dllの部分の;は解除してますが
phpinfoにもPostgresが出てきません
インストールが失敗しているんでしょうか?
一応 ユーザーアカウントを新しくrootとして権限をかけて作りました
Linux環境のサイトが多くWindowsの情報が無く困ってます

Phppgadminのエラー詳細は
データベースをサポートするように
PHP のコンパイル・インストールがされていません。
configure の --with-pgsql
オプションを用いて PHP を再コンパイルする必要があります。


776 :NAME IS NULL:2008/07/04(金) 15:43:53 ID:???
phpinfoに出てこないんじゃ、そもそも無理でしょ。
PostgreSQLが使えるようにビルドしなおすか、
ビルドしたバイナリ持ってくるしかない。

777 :776:2008/07/04(金) 15:49:51 ID:???
ちょっとググってみたけど、extension_dirは設定してる?
そして、extension_dir にちゃんと php_pgsql.dll は入ってる?

778 :NAME IS NULL:2008/07/04(金) 16:09:43 ID:???
>>775
phpinfo();
でpgsqlのセクションが表示されなければ
たぶん、extensions_dirの設定ミス。

つか、Win32版のバイナリなら再コンパイルとか不要で、
ほとんどのオプションはphp.iniの設定変更のみで使用できる。


779 :NAME IS NULL:2008/07/04(金) 18:49:06 ID:???
>>775
Bug #44905 PHP 5.2.6 fails to load PostgreSQL related libraries 
http://bugs.php.net/bug.php?id=44905

これかな?


780 :NAME IS NULL:2008/07/05(土) 20:29:39 ID:???
>>775
Windowsなら大人しくxampp使っておけ
http://www.apachefriends.org/jp/xampp-windows.html
MySQLとかゴミが一緒に入るけど起動しなければ無害
そしてPostgreSQLは別途インストール

781 :NAME IS NULL:2008/07/09(水) 09:40:20 ID:???
プライマリキーのフィールドってインデックス化されるんだったけ?
それとも別途CREATE INDEXしなくちゃいけないの?
他のDBとごっちゃになってきた

782 :NAME IS NULL:2008/07/09(水) 11:05:17 ID:???
プライマリキーを設定するとユニークなインデックスを作成します。
つか設定したときメッセージ出るべ?

783 :NAME IS NULL:2008/07/09(水) 11:26:51 ID:???
>>782
サンクス
メッセージはC#&Npgsqlで直接CREATE TABLE&CREATE INDEXしてたもので出なかったのよ

784 :NAME IS NULL:2008/07/09(水) 11:49:02 ID:???
>>783
調べる基本はドキュメントでしょ。
http://www.postgresql.jp/document/pg833doc/html/sql-createtable.html
の「注釈」を読みましょう。

785 :NAME IS NULL:2008/07/09(水) 15:23:31 ID:???
>>775
PATH設定してみては?
おれもそれっぽいのにぶつかったが、>>777の内容はクリアできてても
phpinfoでは出てこんかった。
とりあえず、PostgreSQLのbinにPATH通したら出てきたよ。

>>779の中にも同じような対処法も書いてある。
(PostgreSQLかPHPのインストーラーでうまくやれよ…と思うんだけど)

786 :NAME IS NULL:2008/07/09(水) 15:44:52 ID:???
textのフィールドを範囲検索かつあいまい検索できるのでしょうか?

仮にtextのフィールド名をmojiretuとして
データが
AAA0001
AAA0002
AAA0003
BBB0001
BBB0002
BBB0003
とあった場合

あいまい検索は
select * from testTable where mojiretu like '%0001'

範囲検索は
select * from testTable where mojiretu >= 'AAA0001' and mojiretu <= 'AAA0002'

これで
AAA0001
AAA0002
BBB0001
BBB0002
だけを引っ張るにはどういうSQL文になるのでしょうか?

787 :NAME IS NULL:2008/07/09(水) 17:44:12 ID:???
or 使えよ

788 :NAME IS NULL:2008/07/09(水) 18:16:49 ID:???
正規表現で
SELECT * FROM testTable WHERE mojiretu ~ '.*000[1-2]'
とか。


789 :NAME IS NULL:2008/07/09(水) 21:11:13 ID:???
LIKEを「あいまい検索」ってのは初めて聞いた。

790 :NAME IS NULL:2008/07/09(水) 23:22:13 ID:???
俺の知り合いにも完全一致じゃないのを「あいまい検索」って言うのがいる。
面倒だからいちいち突っ込まない。

791 :NAME IS NULL:2008/07/09(水) 23:56:57 ID:???
>>789
部分一致をあいまい検索と呼ぶのは、そう呼ぶ客が少なからずいるから、気持ちはわからんでもないのだけど、
>>786の例だと後方一致なんだよなw

792 :NAME IS NULL:2008/07/10(木) 02:02:04 ID:???
テーブル内容が同一の2つのDBがあるのですが、SQLコマンド
一発でDB1のデータをDB2と同一にするような方法はあるもの
でしょうか。

ご教示いただけますと幸いです。

793 :NAME IS NULL:2008/07/10(木) 07:46:45 ID:???
LIKE あいまい検索 の検索結果 約 6,370 件中 1 - 10 件目 (0.20 秒)

794 :NAME IS NULL:2008/07/10(木) 09:38:19 ID:???
>>792
ありません。
レプリケーションの機能は現在のPostgreSQLの弱点の一つです。

795 :NAME IS NULL:2008/07/10(木) 09:38:50 ID:???
って同じにするだけならdumpしてrestoreすればいいけどな

796 :NAME IS NULL:2008/07/10(木) 09:45:59 ID:???
>>795
それだ!

797 :NAME IS NULL:2008/07/10(木) 10:03:10 ID:???
>>788
postgres って正規表現一致使えたのか・・・
永らくそれっぽい検索とかに展開して激しく無駄なことしてたよ・・・
吊ってくる

798 :NAME IS NULL:2008/07/10(木) 14:16:46 ID:???
>>787,788
試してみます、サンクス

>>789-791
お客さんには伝わりやすいのですが
このスレの先輩方のおかげで正式名称がわかりました

799 :NAME IS NULL:2008/07/10(木) 14:27:45 ID:???
俺的にはあいまい検索って言ったら表記の揺れを考慮するやつ。

800 :NAME IS NULL:2008/07/10(木) 16:16:31 ID:???
あいまい三センチ

801 :NAME IS NULL:2008/07/10(木) 16:30:22 ID:???
ぜったい誰か書くと思った。

802 :NAME IS NULL:2008/07/10(木) 21:59:56 ID:???
>>799
たしかに。soundexとかかと思ってしまう。

803 :786:2008/07/11(金) 09:39:13 ID:???
>>788
データが
AAA1999
AAA2000
AAA2001
BBB1999
BBB2000
BBB2001
とあった場合

AAA1999
AAA2000
BBB1999
BBB2000
だけを引っ張るには正規表現では無理なのでしょうか?

804 :NAME IS NULL:2008/07/11(金) 09:56:52 ID:???
どうにでもできるだろ。

805 :NAME IS NULL:2008/07/11(金) 09:59:58 ID:???
substrして数値に変換すれば?

806 :NAME IS NULL:2008/07/11(金) 12:39:25 ID:OI85zmOh
>>803
SIMILAR TO '%(1999|2000)%'
+その他じゃ だめ?
ttp://www.postgresql.jp/document/pg833doc/html/functions-matching.html

807 :NAME IS NULL:2008/07/11(金) 12:46:55 ID:???
そもそもナニを引っ張りたいのかがわからん。

808 :NAME IS NULL:2008/07/11(金) 13:11:48 ID:???
ルールを日本語で表現してくれないと

809 :NAME IS NULL:2008/07/11(金) 13:15:57 ID:???
>>806-807
データが固定的ですいません

文字列3桁 + 数値4桁

このフォーマットでtextフィールドに入れています。

文字列3桁の部分の文字列はlikeなどの一致検索?で
数値4桁の部分の文字列は>=や<=で範囲検索したいのです。

正規表現は一致検索?タイプなので範囲検索には使えないのかなぁ
と思った次第です。

文字列フィールドを>=や<=するのはよくない気がするのですが
実際範囲検索できるので・・・

810 :NAME IS NULL:2008/07/11(金) 13:22:54 ID:???
>>805でいいんじゃないの?
別々の情報なら最初から同じ所に詰め込まない方が良い気もするけど。

811 :NAME IS NULL:2008/07/11(金) 13:37:35 ID:???
>>810
> 別々の情報なら最初から同じ所に詰め込まない方が良い気もするけど

いえ別々のデータというよりは
本の後ろに書いてあるような
ISBN978のような書籍コード?なのです

substringを使用して実現可能なのでしょうか?
発想が貧困なためイメージがわきません・・・

このようなSQLを妄想していたのですが

select * from testTable where mojiretu >= '%0001' and mojiretu <= '%0002'

812 :NAME IS NULL:2008/07/11(金) 13:46:52 ID:???
>>811
文字列3桁 + 数値4桁

substring
で分けて(ry


813 :NAME IS NULL:2008/07/11(金) 13:58:24 ID:???
>>812
数値4桁の部分をsubstringして>=、<=するということですか?わかりません><

select * from testTable where substring(mojiretu, 4, 4) >= '0001' and substring(mojiretu, 4, 4)<= '0002'

814 :NAME IS NULL:2008/07/11(金) 14:04:29 ID:???
例えば、、
substring(mojiretu,4,4) between '1999' and '2000'

815 :NAME IS NULL:2008/07/11(金) 14:12:20 ID:???
まあ0パディング前提だから、数値に変換 (::INT や to_number)してもいい

816 :NAME IS NULL:2008/07/11(金) 14:17:14 ID:???
>>814-815
試してみます!サンクス!

817 :NAME IS NULL:2008/07/11(金) 17:21:18 ID:???
お前ら、優しいな。

818 :NAME IS NULL:2008/07/11(金) 19:21:52 ID:m/805UHa
PostgreSQL 7.4.2 から8.3.3へのリストアでハマってます。

8.3.3ソースを展開>./configure && make
$ su pgsql
$ export LD_LIBRARY_PATH=/usr/local/src/postgresql-8.3.3/src/interfaces/libpq/
$ cd /usr/local/src/postgresql-8.3.3/src/bin/pg_dump/
として8.3.3のpg_dumpを使います。

試したダンプ方法
./pg_dump -F c database > out1.dump
./pg_dump -F p database > out2.dump
./pg_dump database > out3.dump

8.3.3がインスコされたマシンにてそれぞれのダンプファイルを
pg_restore -d database out.dump
としましたが、やたらと改行が入っていたり変な文字に化けたりで・・・

DBのエンコードはEUCです。createdb -E EUC_JPで作ったDBに
export PGCLIENTENCODING=EUC_JP してからリストアしました。

何がイカンのでしょうか?助けて・・・

819 :NAME IS NULL:2008/07/11(金) 20:22:35 ID:???
pg_restore -E EUC_JPは?

820 :sage:2008/07/11(金) 20:28:02 ID:m/805UHa
>>819
どもです。なんか8.3.3は-Eオプションは無いみたいです。
やってみると
pg_restore: invalid option -- E で pg_restore--helpにもありませんでした・・・

$ pg_restore --version は pg_restore (PostgreSQL) 8.3.3 です。

821 :NAME IS NULL:2008/07/11(金) 20:32:25 ID:???
>>820
ダンプの時もEUC_JPにしてる?

822 :820:2008/07/11(金) 20:53:13 ID:???
名前がsageになってもーた・・・

>>820
pg_dumpの直前とpg_restoreの直前にそれぞれのマシン上で
export PGCLIENTENCODING=EUC_JP
として作業しましたところ、日本語が <A1><D6><A5><BF> みたいな
文字列になってしまいました。先ほどは日本語は正常で改行がやたらと
入っているだけだったのですが・・・

createdb時は前後のDB共に-E EUC_JPを作って作成しました。
pg_dumpやpg_restoreの前にpsql -lでEUC_JPになっていることも確認しています。

823 :NAME IS NULL:2008/07/11(金) 21:07:57 ID:???
>日本語が <A1><D6><A5><BF> 
?
EUCじゃねーの?

824 :NAME IS NULL:2008/07/12(土) 02:13:54 ID:???
単に、リストア後に確認している端末で、EUC_JPが表示できていないというオチでは。

825 :NAME IS NULL:2008/07/12(土) 04:27:04 ID:??? ?2BP(1)
>>816 うまくいったら関数indexはっとくといいよ

826 :820:2008/07/12(土) 14:19:58 ID:keLDNTOS
>>823-824
やはりうまく行っていませんでした。
念のため新旧両方のマシンで日本語の表示を確認しましたが
問題なく表示されます。
別のDB(EUC)をリストアしてみたのすが、これも表示がおかしい
のでやはり手順に問題があるのでしょうね。
何か考えられることありますでしょうか・・・?

827 :NAME IS NULL:2008/07/12(土) 15:50:50 ID:???
ver7クライアント(psqlとか)と、ver8.3サーバの
プロトコル互換てありますでしょうか?
事例、調べ方とかでもOKです。

同じように、
ver7のlibpqを使っているPHPがあるのですが、
ver7のlibpqからver8.3サーバの互換についても
お願いします。

※sh、PHPにてver7、8を共存させたい

828 :NAME IS NULL:2008/07/13(日) 10:25:57 ID:???
初心者レベルで申し訳ありませんがよろしくお願いします。


id | integer | not null default nextval('t_memo_id_seq'::regclass)

この値って、無条件にユニークな値を設定するのではないですかね?

insert で

ERROR: duplicate key violates unique constraint

がおきました。

初期 0レコードで
追加したり削除したりで

意識しないといけないのでしょうか?

829 :NAME IS NULL:2008/07/13(日) 10:42:19 ID:???
>>828
自己レス

なんか、プライマリーキーがこわれて重複レコード(キー)が存在しているとう現象があったというURLを
みつけたので

そういうことにしようと思います。

当面、物理的な削除をやめてみます。

830 :NAME IS NULL:2008/07/13(日) 17:17:29 ID:???
なんだかわからんが、max値とcurrent_valと比較してみては

831 :NAME IS NULL:2008/07/13(日) 17:32:59 ID:???
そもそも default nextval() なフィールドは、デフォルト値が使われる
以外の操作で変更できてしまうからな。
勝手な値でinsertとかupdateされたんじゃないの?

832 :NAME IS NULL:2008/07/14(月) 00:36:41 ID:???
テーブル容量計算したいんですけど、
どっかに良いテンプレート公開している所ありませんか?

833 :NAME IS NULL:2008/07/14(月) 06:06:42 ID:???
>>830-831

レスありがと。

3回くらい、ERRORになったあと、追加できるようになりまして、テストのときから見なかった現象なので・・・。
再現したら、考えます。

834 :NAME IS NULL:2008/07/14(月) 12:20:06 ID:???
>>832
今あるテーブルを計測するなら
>>387

レコードあたりのバイト数から算出するExcelとかが欲しいならしらにゃい

835 :NAME IS NULL:2008/07/14(月) 21:05:46 ID:???
とりあえず1行INSERTしてみて、pgstatupleして、結果を想定行数倍したら?

836 :NAME IS NULL:2008/07/18(金) 04:13:24 ID:trTm/p1R
SELECT文について教えて下さい。

これまでグループごとのデータ件数を次のようなSELECT文で取得していました。

SELECT group_id ,COUNT(id) as count
FROM mytbl
GROUP BY group_id
ORDER BY group_id;

各データには登録日という項目があるのですが、グループごとに、
登録から60日以内のデータ件数、登録から60日超のデータ件数を
1回のSELECT文で取得することは可能でしょうか?

perlからSELECT文を発行しているので、上記SELECT文の結果に対してループを使って

SELECT COUNT(id) as count
FROM mytbl
WHERE group_id='101' and age(date)<='60 days';

SELECT COUNT(id) as count
FROM mytbl
WHERE group_id='101' and age(date)>'60 days';

とすることで求めるデータは取得できるのですが、1回でできる方法があれば教えて
下さい。

837 :NAME IS NULL:2008/07/18(金) 04:53:33 ID:???
>>836
SELECT group_id,
sum(CASE WHEN age(date) <= '60 days' THEN 1 ELSE 0 END) AS 60日以内,
sum(CASE WHEN age(date) <= '60 days' THEN 0 ELSE 1 END) AS 60日超
FROM mytbl GROUP BY group_id ORDER BY group_id;

838 :836:2008/07/18(金) 13:50:35 ID:Qo8rMDkV
>>837
ありがとう!やってみます。

839 :NAME IS NULL:2008/07/22(火) 01:25:40 ID:???
>>818, 820

[ OLD SERVER ]
pg_dump -F p -s -v -i -f hoge-schema.sql hoge-db
pg_dump -F p -a -v -i -O -f hoge-data.sql hoge-db

スキーマ(テーブル定義)と中身(データ)を分けて出力

[ NEW SERVER ]
su - postgres
psql -l
# DBがあれば一旦DROPで
# dropdb hoge-db
$PG_HOME/bin/createuser foo
$PG_HOME/bin/createdb -O foo -E EUC_JP hoge-db

# 確認してrep_str.sh を実行(とりあえず改行取るだけ。CRLF -> LFに)
ls -l
./rep_str.sh

[ rep_str.sh 中身 ]
---
#!/bin/sh
sed -e 's/\\r\\n/\\n/g' hoge-data.sql > hoge-data2.sql
---

# スキーマは -U なし。データはDB接続アカウントの権限で実行
psql -d hoge-db -f hoge-schema.sql
psql -d hoge-db -U foo -f hoge-data2.sql

psql -d hoge-db -f alter-hoge.sql

wgetかなんかでOLDServerからDLした後、DB作成してコマンドとAlterのSQLをま
とめて実行かけて、適切なACLを設定。

[ alter-hoge.sql ]
----
ALTER TABLE bar OWNER TO foo;
REVOKE ALL ON TABLE bar FROM postgres;

PostgreSQLの管理アカウント名に注意してください。
かたや postgresql で かたや pgsql だとマズーなんで。

以上


840 :NAME IS NULL:2008/07/24(木) 14:01:20 ID:???
なんか postmaster が8.2から廃止されているぽいんだが
ttp://www.postgresql.jp/document/pg820doc/html/app-postmaster.html
この辺の経緯の資料はないかな?

RHEL5 + PostgreSQL 8.3.1 の環境で

pg_ctl start
pg_ctl status

とやって動作確認したら
==============================
pg_ctl: server is running (PID: 8905)
/usr/bin/postgres
==============================
こんな感じになって、シングルユーザモード!?と最初焦ったんだ。

841 :NAME IS NULL:2008/07/24(木) 14:10:30 ID:???
postmasterはかわってないよ。
pg_ctl の表示の仕方がかわっただけでしょう。

試しに同じDBで、8.31の環境で新しいpg_ctl使ったら server、8.2のpg_ctl使ったら postmaster と出ましたよ。
ps で見てみるのが確実かもね。

842 :840:2008/07/24(木) 14:24:02 ID:???
あれ?そうなんだ。8.2以降のpostmasterのドキュメント説明が
「postmasterはpostgresの廃止予定の別名です。」
に変わっていて、psで見ても postgres になっているからてっきり。

確認し直してみると、「postmaster」で直起動してpsすると
名前がpostmasterに、「pg_ctl start」で起動してpsすると名前が
postgresになる模様。

どちらの場合も「pg_ctl status」で様子を見ると
==============================
pg_ctl: server is running (PID: 8905)
/usr/bin/postgres
==============================
と出る。ううむ。

843 :NAME IS NULL:2008/07/24(木) 14:39:24 ID:mBwHhXoV
本体はpostgresになって、postmasterはリンクになりましたよ、ってことでしょ。
pg_ctlなんかはそれに合わせて作り直されているけど、起動スクリプトなんかは
postmasterを呼び出すままになってるだけなんじゃ。

postmasterが廃止方向なのは、MTAがらみと混同してしまうからかな?
今更のような気もするけど。

844 :NAME IS NULL:2008/07/24(木) 15:11:53 ID:???
でもそれ昔からだった気がするけど。

845 :NAME IS NULL:2008/07/24(木) 21:33:50 ID:Z/swGqhj
8.3.3 からのXMLの機能ってこの本役に立つ>「標準講座 XQuery」
経験無いから、購入迷ってるんだけど
それとも、他にいい本ありそう?

846 :NAME IS NULL:2008/07/25(金) 00:53:18 ID:???
>>843 MTAがらみと混同
それもあった。他に、シンボリックリンクをサポートしていない
Windows版で、インストーラのサイズを小さくするためもあったような。
postgres と postmaster の同一バイナリを2つ含んでいるのは無駄だったから。



847 :NAME IS NULL:2008/07/25(金) 02:10:54 ID:???
インストーラがコピー作るようにすればサイズ変わらんと思うけど

848 :NAME IS NULL:2008/07/29(火) 22:09:41 ID:???
これとオラクルの連携ってどんな感じ?

849 :NAME IS NULL:2008/07/29(火) 22:10:24 ID:WgByyyeH
ついでにage

850 :820:2008/07/30(水) 01:30:46 ID:???
>>839
上手く行きましたああああああああああああ。
あざーーーーーーーーっす。

851 :NAME IS NULL:2008/08/01(金) 11:22:34 ID:Vlj4h0JM
clusterしたら select文で

Relation "t_table" with OID 68308374 no longer exists

って出るようになっちっち。( TДT)
調べたらキャッシュのOIDと違うようなんだけど、どうすればキャッシュのクリア。
もしくは整合性をとれるようになりますか。
教えてエロい人。

852 :NAME IS NULL:2008/08/01(金) 13:15:46 ID:???
>851
自己レスです。
エラー文出てたのは、clusterしたテーブルのviewテーブルをselectした時だったのですが
viewテーブルをDROPしてcreateしなおしたら、エラーでなくなりました。
すんません。

853 :NAME IS NULL:2008/08/01(金) 19:35:11 ID:???
>>852
やけにバージョンが古くないか?
最近のならそれくらいではエラーにならないと思うんだけど。

854 :NAME IS NULL:2008/08/02(土) 15:35:04 ID:IADhYOwn
ttp://erogamescape.ddo.jp/~ap2/ero/toukei_kaiseki/select.php
ここのSQLのCGIからデータを参照したいのですが・・・

テーブルリスト ttp://erogamescape.ddo.jp/~ap2/ero/toukei_kaiseki/tablelist.php

発売日・ゲーム名 だけをリストアップする場合は、
SELECT sellday, gamename FROM gamelist
で出来たんですが、テーブルをまたぐデータ参照のやりかたがわからないのです orz

発売日・ブランド名・ゲーム名 をリストアップする場合、どう書けばいいでしょうか?
gamelist.selldayが発売日。 gamelist.gamename がゲーム名。
gamelist.brandname と brandlist.id が対応するかたちで、
ブランド名は、brandlist.brandname にあります。

855 :NAME IS NULL:2008/08/02(土) 16:53:51 ID:/jmwO2I5
>>854
SELECT * FROM gamelist JOIN brandlist ON gamelist.brandname=brandlist.id

856 :NAME IS NULL:2008/08/02(土) 18:27:26 ID:???
>>855
ありがとうございます。
やっと思い通りにリストアップする事ができました。

857 :NAME IS NULL:2008/08/03(日) 19:00:59 ID:et0fI5Cl
PostgreSQL 8.3.3をWindowsXPで使用しています。
鯖はutf-8で、client_encodingでSJISを指定しているのですが、
COPY時のパス、ファイル名に日本語が含まれていた場合、失敗します。
日本語のファイル名で読み込ませるにはどうすればいいか教えてください。

'e:/日本語/hoge.txt' ← could not open file "e:/日本語/hoge.txt" for reading: No such file or directory
'e:/hoge.txt' ← コピー成功

858 :NAME IS NULL:2008/08/04(月) 08:15:39 ID:???
>>857
サーバエンコーディングとOSのエンコーディングを一致させている環境でないとダメ。
特に、鯖にSJISが使えないので、Windowsでは無理なのです。昔からある不具合。

859 :NAME IS NULL:2008/08/04(月) 09:55:32 ID:???
PostgreSQLへVB.NETから接続したいのですが
一番メジャーな方法は何でしょうか?

860 :NAME IS NULL:2008/08/04(月) 09:56:54 ID:Qg+jh4Ky
>>859
Npgsqlでいいんじゃね。

861 :NAME IS NULL:2008/08/04(月) 10:01:40 ID:???
>>860
ありがとうございます。試してみます。

862 :857:2008/08/04(月) 19:56:49 ID:???
>>858
レスありがとうございました。
素直に英数字を使うことにします。

863 :NAME IS NULL:2008/08/07(木) 15:14:49 ID:???
pgcluster-1.9系,1.7系,1.5系 それぞれの最新バージョンをテストしているのですが、pglbを通してdropdbすると、それ以降pglbが接続を受け付けない(psqlすると無反応)状態になってしまいます。
構成はINSTALL_PGCLUSTER通りの、LBx1,RPx1,CLx2で、OSはCetnOS4です。

debugログを見ると、dropdb時にpglbをHUPしているようなのですが、その後おかしくなっているみたいです。プロセスは残っていますが、pglbのpidファイルは削除されてます。

その状態でも、直接ClusterDBには正常に接続できますし、レプリケーションも機能します。

pgpool-3.4.1をpglbの元にしているバージョン以降での現象のようですが、同じ現象を経験された方や、解決方法をご存知の方いらっしゃいますか?

864 :NAME IS NULL:2008/08/09(土) 12:10:53 ID:???
同じPCで、Windowsだとpgbenchで80tpsくらい、Linuxだと500tpsくらい出るんだけど、
なんでWindowsだとこんなに遅いの?

865 :NAME IS NULL:2008/08/09(土) 14:30:37 ID:???
>>864
Windowsのほうが遅いのは確かだけど、それは差がつきすぎな気が。
チューニングしていないなら、WAL関係だけでもやってほうが良いかも。
(checkpoint_segments, wal_sync_method)

まぁ、性能が必要ならWindows版は避けたほうが無難。
ちょっと機能を試すだけならお手軽で良いんだけど。

866 :NAME IS NULL:2008/08/10(日) 23:13:39 ID:???
textとcharacter varying(varchar)のデータ型の使い分けの
基本的な考え方を教えて下さい。
webで探すとtext型を推奨するような書き込みもありますが、
お互いで得手不得手な事があるのでしょうか?


867 :NAME IS NULL:2008/08/10(日) 23:46:39 ID:???
>>866
DB側で文字数の制限およびチェックが必要かどうかだけ。
と思ってる。

868 :NAME IS NULL:2008/08/11(月) 04:43:15 ID:???
>>867
それでOK。実装はまったく一緒だし。
管理ツールで表示が違う場合はあるかも。
varcharは1行テキストボックス、textは複数行テキストボックスとか。

869 :NAME IS NULL:2008/08/11(月) 11:05:33 ID:JHhGIW9s
Macのヒラギノで表現できる文字(Adobe-Japan1-5 JIS X 0213? + Unicode?)を全て格納したいのですが、
DBの文字コードは何を指定したらいいのでしょうか。

http://www.apple.com/jp/pro/design/typography/05/index6.html
を読んでいると、全てを文字コードで格納するのは不可能とも読み取れますが・・
UTF-8にしておくのが一番いいのでしょうか?

870 :866:2008/08/11(月) 13:45:48 ID:???
>>867-868
なるほど、ありがとうございました。


871 :NAME IS NULL:2008/08/12(火) 07:29:17 ID:???
ヒラギノのことはよく知らんけどUnicodeで表現できるならUTF-8でいいんじゃ?
表現できなきゃ、バイナリデータとして格納とか。

872 :NAME IS NULL:2008/08/16(土) 12:56:12 ID:iPeeVtKy
〉863
それ、おれもなった。
結局解決つかなかったからpgpool使ったよ。

873 :NAME IS NULL:2008/08/18(月) 04:35:12 ID:rrvhCdtj
VACUUMのためにDB鯖を2台用意し
1台を通常運用、ある一定時刻がきたらデータをすべて
2台目のDB鯖に写しアプリからもデータ更新不可・2台目の鯖接続というように処理させ
1台目のVACUUM処理終了後、通常運用に戻るというような
運用はありでしょうか?
何かネックになりそうなことはありますでしょうか?

874 :NAME IS NULL:2008/08/18(月) 06:17:41 ID:???
2台目のサーバで行われた更新を
どうやって1台目に反映させるの?

875 :NAME IS NULL:2008/08/18(月) 06:48:38 ID:???
ありがとうございます。
2台目の鯖運用時は参照のみに利用し、更新は行いません。
ということです。

876 :NAME IS NULL:2008/08/18(月) 08:11:16 ID:???
>>875
特に問題はないと思う。2台目のデータは毎回捨てるってことだよね?
ただ、目的がVACUUM中の性能低下を回避するだけならば、
サーバ間のデータコピーが本当にVACUUMより軽いか調べたほうが良いかも。

877 :NAME IS NULL:2008/08/18(月) 08:50:25 ID:???
pgpoolとかで同期させといて
バキュームしたい時、意図的に切断しとけば?

878 :NAME IS NULL:2008/08/18(月) 16:14:41 ID:???
>>872
レスありがとうございます。そちらの環境でもなりましたか。
すぐ気付きそうな現象ですから、情報が出ていてもよさそうなもんですが、無いんですよね。

2008-03-09以降リリースのバージョンで、pglbのdropdb上手くいっている人いましたら、是非環境を伺いたく。

879 :NAME IS NULL:2008/08/19(火) 00:12:40 ID:qDOKASZt
複合PKを持っている表を
ID+UNIQUE制約に変更したいときに、
既存データにID値を振りなおす(採番する)のって
serial型をADD COLUMNするだけで行けます?

日本語わかりにくかったらごめんなさい。

880 :NAME IS NULL:2008/08/19(火) 08:51:25 ID:???
>>879
カラム追加だけだと中身がNULLじゃね?

881 :NAME IS NULL:2008/08/19(火) 10:02:35 ID:???
連番振るだけなら一発でできるよ。
シリアル追加だけじゃ何も入らない。

882 :NAME IS NULL:2008/08/19(火) 10:21:33 ID:???
>>879
実はその新規連番付与にも複雑な法則性が…
なんて後出しが来ないことを祈るwww

883 :881:2008/08/19(火) 10:34:12 ID:???
あれ?
今試したら、しっかり番号入ってる。

すみません、ALTER TABLE table ADD COLUMN no SERIAL;
だけで入ってました。8.1.4ですが

884 :NAME IS NULL:2008/08/20(水) 01:18:01 ID:???
クラサバの接続とApache+PHPでの接続、利用はわかるのですが、
WebサーバーのPostgreSQL へVB.NET または、VB6での接続は可能でしょうか?
可能であれば、その方法をご存知の方いましたら、教えて下さい。
WebサーバーへのODBC接続は試みましたがうまくいきませんでした。

885 :NAME IS NULL:2008/08/20(水) 07:57:05 ID:???
>>884
ODBCでも良いし、Npgsqlでも良いし、お好きな方法で。
事象の報告もなしに「うまくいきません」といわれても、これ以上のアドバイスは無理。

886 :NAME IS NULL:2008/08/20(水) 08:39:19 ID:???
>>884
「WebサーバーへのODBC接続」
文脈から理解できるが言葉の意味をしっかり押さえるべき

887 :NAME IS NULL:2008/08/20(水) 09:52:09 ID:???
PostgreSQLのODBCドライバがインストールされて無いんじゃないの?
まず、開発用PC(Win?)からWebサーバ上のPostgreSQLにODBC接続可能かどうか試しましょう。

OKならVB6ならADODB、VB.NETならADO.NETで接続可能なはず。
ADO.NETではODBC接続は速度的に使いものにならないからNpgsqlが無難だね。

888 :NAME IS NULL:2008/08/21(木) 00:13:36 ID:???
884です。
みなさん、ご教授ありがとうございます。
できるようになりました。
ポートが空いていなかったのが原因でした。
できれば、必要なポートだけを開けたいのですが、
PostgreSQLで必要な5432など以外に何が必要なのでしょうか?

889 :879:2008/08/21(木) 02:16:48 ID:???
こんなに早く回答もらえると思ってなかったので遅くなりました
ありがとうございます。

実際に試せるのはもうちょっと先になるんですが
ハードが物理的におかしくなってそれどころじゃなくなって
泣きそうです ><


890 :NAME IS NULL:2008/08/21(木) 17:41:24 ID:???
>>888
標準では5432tcpだけあけとけば問題ないよ
> PostgreSQLで必要な5432など以外に何が必要なのでしょうか?
これはPostgreSQL以外で必要となるポートと言ってますか?

891 :NAME IS NULL:2008/08/22(金) 18:49:17 ID:???
>>890
888ですが、
5432だけで、いいのですか。
ありがとうございます。
今のところ、それだけでは、うまくいきませんが、試行錯誤してみます。

892 :NAME IS NULL:2008/08/22(金) 19:00:47 ID:???
それだけでうまくいかないのは、別の原因か設定ミス

893 :NAME IS NULL:2008/08/23(土) 23:17:25 ID:???
PostgreSQLの問い合わせの方法の中にビットマップスキャンというのが
ありますが,そもそもビットマップとは何なのでしょうか?
windowsのビットマップ画像でないと思うのですが,それではいったい何を示しているのか
わかりません
わかる方いたらお願いします

894 :NAME IS NULL:2008/08/24(日) 07:41:58 ID:???
ググれ

895 :NAME IS NULL:2008/08/25(月) 12:46:22 ID:???
http://xn--lckja1b6r.jp/%E3%83%93%E3%83%83%E3%83%88%E3%83%9E%E3%83%83%E3%83%97%E3%82%B9%E3%82%AD%E3%83%A3%E3%83%B3

896 :NAME IS NULL:2008/08/28(木) 19:53:10 ID:???
debianにインストールしたのですが、ローカルでは問題なく動くのですが、
別マシンから接続すると、

psql: could not open certificate file "/home/orca/.postgresql/postgresql.crt": そのようなファイルやディレクトリはありません

となってしまいます。
このファイルは、どういうタイミングで作られるんでしょうか?

897 :NAME IS NULL:2008/08/28(木) 23:25:43 ID:???
>>890
>>888でできるようになりました、と書いているが、>>890でうまいくいきませんと書いているわけで、
何ができて何ができていないのかが伝わってこないのが現状です。
よくわからんので、Webサーバの80tcpを開けてみたら?

>>896
SSL関連のように思うが、それは意図的にそういう接続を?

898 :NAME IS NULL:2008/08/29(金) 08:58:19 ID:???
>>897
>SSL関連のように思う
とあるソフトのインストールを、手順書の(OSのインストール手順からある)通りにやっていたんですが、
SSLの設定の事は何処にも書いてないんで、Postgerの問題かと思ったのです。

SSLのセットアップから試してみます。

899 :NAME IS NULL:2008/08/29(金) 18:03:21 ID:???
oracleにあるselct for update wait のような
行ロックを掛けつつタイムアウトを設定するには
どうすればいいでしょうか?

900 :NAME IS NULL:2008/08/30(土) 05:40:20 ID:???
>>899
それ、タイムアウト設定じゃなくて
ロックされてたら待機するかエラー返すかのオプションだろwww
PostgreSQL8.1あたりからNO WAITが使えるようになった、
ってことは、これまでのはWAITだったってことだ。


901 :NAME IS NULL:2008/08/30(土) 09:41:07 ID:???
>>900
すみません。ちょっと説明不足でした。
oracleはselect for update wait 10
とすると10秒待機してエラーになります。
このような設定はないでしょうか?

902 :NAME IS NULL:2008/08/30(土) 10:02:33 ID:???
>>901
SQLだけでやりたいなら、statement_timeoutと組み合わせるのかな。
 BEGIN;
 SET LOCAL statement_timeout = '10s';
 SELECT ... FOR UPDATE;


903 :NAME IS NULL:2008/08/30(土) 10:17:50 ID:???
>>902
おぉ!
さんくす。

904 :NAME IS NULL:2008/09/03(水) 17:54:16 ID:???
age 関数が使えない(=結果が微妙な)んだけど、うちの環境だけ?

# select age(timestamp '2009-09-02', timestamp '2008-09-03');
 11 mons 29 days

期待しているのは、11 mons 30 days なんですがねぇ。

# select age(timestamp '2009-09-01', timestamp '2008-09-03');
 11 mons 28 days

# select age(timestamp '2009-08-31', timestamp '2008-09-03');
 11 mons 28 days

なんてなるし。環境は

# select version();
 PostgreSQL 8.1.13 on i686-pc-linux-gnu, compiled by GCC gcc (GCC) 3.3.1

です。

905 :NAME IS NULL:2008/09/03(水) 21:03:59 ID:???
>>904
仕様だな。

# select age(timestamp '2009-09-02', timestamp '2008-09-03');
11 mons 29 days

# select age(timestamp '2009-08-02', timestamp '2008-08-03');
11 mons 30 days

# select age(timestamp '2009-02-02', timestamp '2008-02-03');
11 mons 28 days

# select age(timestamp '2010-02-02', timestamp '2009-02-03');
11 mons 27 days

# select version();
PostgreSQL 8.3.3 on i686-redhat-linux-gnu, compiled by GCC gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-14)

906 :NAME IS NULL:2008/09/03(水) 21:25:38 ID:???
>>905
その結果だけを見ると、単に当日を含むか含まないかの問題のように見えますが
問題はそうじゃないんですよね。

# select age(timestamp '2009-09-03', timestamp '2008-09-03');
 1 year

ですし。問題は

1. 2008-09-03 → 2009-09-03 は 1 年(当日を含まないなら、ここが変わるはず)
2. 2008-09-03 → 2009-09-02 は 11 ヶ月 29 日(8 月は 31 日あるから 30 日を期待)
3. 2008-09-03 → 2009-09-01 は 11 ヶ月 28 日
4. 2008-09-03 → 2009-08-31 は 11 ヶ月 28 日(上の 09-01 と同じ結果)

という結果になることなんです。結果がこうなっている以上は仕様なんでしょうけど
これだと、異なる日との差分で同じ結果になることがある(3. と 4.)ので、
微妙に使えない(と私は思う)仕様ですね。

907 :NAME IS NULL:2008/09/03(水) 23:19:12 ID:???
そこが問題になるなら普通に引き算して日にちを出せばいい

908 :NAME IS NULL:2008/09/03(水) 23:20:58 ID:???
intervalを無理に年月日に振るからこうなる

909 :NAME IS NULL:2008/09/03(水) 23:29:13 ID:???
>>907
日数を出すだけで良いなら、最初からそうしますって。
関数ないかなーって探して見つけたと思ったら、上記の
結果だったので、使えない関数だなぁと思って。
誰も問題視してないんでしょうかね。
少なくとも違う日で同じ差分が出るのは問題でしょ。
仕方ないので関数を自作します。

>>908
無理にっていっても、単なるキャストとかじゃなしに、
専用の関数ですよ。内部でどうにでもなるじゃないですか。

910 :NAME IS NULL:2008/09/03(水) 23:48:28 ID:???
さすがウンコDB

911 :905:2008/09/04(木) 01:10:58 ID:???
>>906
あーなるほど、今まで気づかなかった。
マニュアルより
> 異なる月では日数が異なりますのでageで返されるmonthsにはあいまいさがあります。
> PostgreSQLのやり方は月にまたがる2つの日付の計算において、日付の早いほうの月を使用します。

今まで気づかなかったくらいだから、それほど困る場面に直面するわけでもなさそうだが、
頭の片隅においといた方が良さそうね。

912 :NAME IS NULL:2008/09/04(木) 02:27:58 ID:???
>>911
なにー、マニュアルに書いてあったんですか。
http://www.postgresql.jp/document/pg833doc/html/functions-datetime.html
の 9.9.1 の直前ですね。age 関数の説明までしか見てませんでした。すみません。
それなら、完璧に仕様ですね。諦めて自作で進めます。

913 :NAME IS NULL:2008/09/04(木) 04:14:41 ID:???
そもそも、日付の差を取ったときに、何月という情報は
論理的な意味を失うと思うんだが。


914 :NAME IS NULL:2008/09/04(木) 08:25:36 ID:???
単に age() と operator - () の2つ選択肢があるってことじゃないの?
用途に応じて使い分ければ良いのでは。
確かに age のほうは使い道がビミョーだが。

915 :NAME IS NULL:2008/09/04(木) 12:04:55 ID:???
どこかの国の法律か、どこかの業界の慣習(たとえば保険?)とかで、
このageみたいな定義で計算することになっているところがあるのかも。

916 :NAME IS NULL:2008/09/08(月) 21:48:18 ID:hDzPVYxs
pgAdminIIIを開いて、画面左側のサーバー一覧からサーバーを選択して
「サービス開始」を実行するとエラーになります。

エラーが起こりました:
Failed to start server pgsql-8.0: Errcode=1069
Check event log for details.

のエラーメッセージが出ます。インストールしたフォルダ
D:\Program files\PostgreSQLやそのサブフォルダの中から該当するログファイルを探して
原因を調べようとしたけど、更新日付が今日のファイルが見つからないし、全くどうなって
るのかわかりません。

前はサービスが開始してて動いてたはずなのに、何でエラーになるんでしょうか。


917 :NAME IS NULL:2008/09/08(月) 22:41:10 ID:???
>>916
event logはWindowsの機能。
コンパネ>管理ツール>イベント ビューア
で見てみて。

918 :NAME IS NULL:2008/09/12(金) 01:38:47 ID:???
・standard_conforming_stringsがONのとき、
・非E''構文で、
DB内の改行文字(その他エスケープ構文)を検索することは出来ない、ですか?

「nonstandard use of escape in a string literal」の警告消したくて試してたら
こっちが気になりました。
(警告は消えたし改行文字を検索したい場面も
 無い気はしますが知識として気になったので)


919 :NAME IS NULL:2008/09/12(金) 02:33:30 ID:???
>>918
\\nでは?

920 :918:2008/09/12(金) 23:41:09 ID:???
しょぼ……

自己解決しました。
エスケープ系は不可ですが、
改行文字自体を検索キーにすればヒットしますね。(当たり前w)

>>919
・standard_conforming_stringsがON
・非E''構文
だと、「\\n」は「\\n」という文字に対してのみマッチします。
(\が特殊な意味を持たなくなるので
 where hoge = '\' みたいな時にエラーにならない)

※他人に講釈するほど詳しくないので違ってたら指摘ヨロ


921 :NAME IS NULL:2008/09/20(土) 19:10:36 ID:???
業務で使うとしたら、8.1〜8.3ではどれが一番安定してんのかなー

922 :NAME IS NULL:2008/09/21(日) 00:16:16 ID:???
>>921
おまえの脳が一番の不安定要因だから心配するな

923 :NAME IS NULL:2008/09/21(日) 00:41:19 ID:???
業務で使うのに休日に2chで質問するなよ

924 :NAME IS NULL:2008/09/21(日) 05:10:09 ID:???
ですよね

925 :NAME IS NULL:2008/09/21(日) 09:53:04 ID:???
自分で判断できないならば、とにかく一番新しいの使っておけばいいよ。

926 :NAME IS NULL:2008/09/21(日) 09:55:23 ID:???
VACUUM少ない8.3にしろ。

927 :NAME IS NULL:2008/09/21(日) 11:41:06 ID:???
8.3の最新版でも、データ飛ぶとかの致命的な問題はないんでしょ?

928 :NAME IS NULL:2008/09/21(日) 12:10:34 ID:???
どのバージョンにデータ飛ぶとかの致命的な問題があるの?

929 :NAME IS NULL:2008/09/21(日) 12:26:29 ID:???
8の最初の頃

930 :NAME IS NULL:2008/09/21(日) 23:01:14 ID:???
データが飛ぶようなバグってほんとうにレアケースだから、
見つかるときは全バージョンで修正が入るような。
新しいからといって不安定なようには見えない。

931 :NAME IS NULL:2008/09/22(月) 01:33:55 ID:???
8.2であったデータ飛ぶってのもvacuumしたときにごくまれな条件で飛ぶかもって程度だしな

932 :NAME IS NULL:2008/09/22(月) 16:18:02 ID:???
業務で使うのに平日に2chで質問されてもいやじゃん。

933 :NAME IS NULL:2008/09/22(月) 22:27:49 ID:???
どこの業者もそんなもんだから平日は我慢しろ

934 :NAME IS NULL:2008/09/24(水) 02:08:48 ID:32cC4wGg
8.3.4 / 8.2.10 / 8.1.14 / 8.0.18 / 7.4.22 updated
けっこうバグが修正されてるぽ。

935 :NAME IS NULL:2008/09/24(水) 02:54:11 ID:???
調整が終わって一昨日やっと本番環境8.3.3にウプデートした俺涙目

936 :NAME IS NULL:2008/09/24(水) 08:05:31 ID:???
http://www.postgresql.org/docs/current/static/release-8-3-4.html
急いでバージョンアップしなくてもよさそうだけど
週末あたりにやるか。

937 :NAME IS NULL:2008/09/26(金) 05:32:04 ID:J6N79vWq
sequenceとnextvalで連番を簡単に管理できるのですが、
レコード内の1フィールドにnextvalを適用する方法はないのでしょうか。

name, counter
yamada, 3
tanaka, 10
suzuki, 20

nameを指定してcounter部分をインクリメントさせたいのです。

938 :NAME IS NULL:2008/09/26(金) 07:11:05 ID:???
>>937
ふつうにUPDATEしたら?
UPDATE tbl SET counter = counter + 1 WHERE name = 'yamada';

939 :NAME IS NULL:2008/09/26(金) 10:08:57 ID:???
>>937
トリガーでnameに応じてシーケンスを使い分ける

940 :NAME IS NULL:2008/09/26(金) 16:42:46 ID:UeZFxsYq
CentOS3.6のMySQL(3.23.58)でBDBテーブルを作りたいんですが
リコンパイルする必要があるのでしょうか?
或いはリコンパイルする必要があるか確認する方法はありますでしょうか?
リコンパイルする必要がないのでしたらどのようにしたら
BDBテーブルが作れるようになる設定や環境などあるのでしょうか?

現状create tableでTYPE=BDBを指定してもエラーにはならないのですが
出来上がったテーブルはMyISAMになってしまいます。


941 :NAME IS NULL:2008/09/26(金) 16:43:47 ID:UeZFxsYq
↑誤爆してすいませんm(__)m

942 :NAME IS NULL:2008/10/02(木) 17:24:01 ID:???
思わず茶を吹いてしまったwww
ttp://www.postgresql.org/about/news.1013


943 :NAME IS NULL:2008/10/02(木) 17:42:49 ID:???
なんだこれ。おもしれーw

944 :NAME IS NULL:2008/10/03(金) 17:16:42 ID:???
知ってる人居たら教えてください。

今CentOS+Postgres8.3+pgpool2.1を使ってレプリケーション構築してて、
障害時のオンラインリカバリのために事前準備してるんだけど、
pgpoolIIのREADMEにあるC言語関数のインストールで躓いた。
こんなエラーが吐かれる

/psql -f /usr/local/pgsql/share/contrib/pgpool-recovery.sql template1 ←これを実行

ERROR: incompatible library "/usr/local/pgsql/lib/pgpool-recovery.so": missing magic block
HINT: Extension libraries are required to use the PG_MODULE_MAGIC macro.
STATEMENT: CREATE OR REPLACE FUNCTION pgpool_recovery(text, text, text)
RETURNS bool
AS '$libdir/pgpool-recovery', 'pgpool_recovery'
LANGUAGE C STRICT;
psql:/usr/local/pgsql/share/contrib/pgpool-recovery.sql:4: ERROR: incompatible library "/usr/local/pgsql/lib/pgpool-recovery.so": missing magic block
HINT: Extension libraries are required to use the PG_MODULE_MAGIC macro.

PG_MODULE_MAGIC入れろって事みたいなんだけどソース見たらちゃんとインクルードされてる・・・
ググってもドンピシャな内容がヒットしないんだけど俺だけ?

945 :NAME IS NULL:2008/10/03(金) 17:25:08 ID:???
>>944
#include っつーか、ちゃんと #define される条件(#ifdef)になってるの?

946 :NAME IS NULL:2008/10/03(金) 17:37:47 ID:???
>>945
レスありがとう。

ごめん、C言語はよく解らない・・・
コンパイルするソース(pgpool-recovery.c)には

#ifdef PG_MODULE_MAGIC
PG_MODULE_MAGIC;
#endif

っていう記述がある。

これでできた共有オブジェクトを各データベースノードに持っていってるんだけど・・・


947 :NAME IS NULL:2008/10/03(金) 17:49:17 ID:???
それ、8.2.0より前の環境はじくのに使われてるけど、
/usr/local/pgsql/include/server/fmgr.h の中ではdefineされてる?

948 :NAME IS NULL:2008/10/03(金) 18:01:34 ID:???
>>947
defineされてた!

今Postgresqlのインストールディレクトリが、/usr/local/postgres-8.3.3ってなってるから、includeディレクトリが見えてないのかな?
ちょっとコンパイルしなおしてみる!ありがとう!

949 :946:2008/10/03(金) 18:33:51 ID:???
>>947
解った!
コンパイル結果をよく見てみると

usr/include/pgsql/server -I/usr/include/pgsql/internal

っていうメッセージが出てる!
ここのヘッダファイルには全然PG_MODULE_MAGICが定義されてなかった!

何とかしてinclude先を変えられればうまく行きそう!

950 :NAME IS NULL:2008/10/03(金) 18:38:38 ID:???
OSインストール時に一緒にインストールされたやつか。
頻繁にソースから入れる人には邪魔かもな。

951 :NAME IS NULL:2008/10/03(金) 19:00:25 ID:???
元々入っていたPostgreSQLをアンインストールする方がいいような。
yum --remove postgresql-devel 的なかんじで。

952 :946:2008/10/03(金) 20:07:49 ID:???
>>946です

無事に解決できました!
皆さん本当にありがとうございました!

結果的に、コンパイル時にMakefileの中で発行されているpg_config --pgxsが、OSインストール時に
入っていた古いPostgreSQLのpg_configでした。

>>951のアンインストール(yum remove postgresql)を実施して、ちゃんとPostgreSQL8.3のpg_configに
パスを通す事でちゃんとC言語関数がインストールできました。

何か皆さんが的確に原因を指摘してきてくれた事に感動しました!


953 :951:2008/10/03(金) 20:11:19 ID:???
>>952
おめでとう!

けれど、アンインストールした状態で (一応/usr/include/pgsql がないことを確認して)
あらためてconfigure する方がいいよ
状態に応じて最適なMakefileを作ってくれるのがconfigureなので。

954 :NAME IS NULL:2008/10/04(土) 19:17:29 ID:DCYl0+1j
すいません、質問です。
CentOS5.2にPostgreSQL8.4をインストールしたのですが、
pg_ctl start
しようとすると

> FATAL: database files are incompatible with server
> DETAIL: The data directory was initialized by PostgresSQL version 8.1, which is
> not compatible with this version 8.4devel.

と表示されてしまい起動できません。
確かに一度8.1をインストールしているのですが、こういう場合、
OSごとインストールしなおすしかないんでしょうか?

955 :NAME IS NULL:2008/10/04(土) 19:22:28 ID:???
>>954
8.1 を使ったことがある(データがある)かないかにもよるけど?

956 :NAME IS NULL:2008/10/04(土) 20:23:23 ID:???
initdb -D 新しいデータベースディレクトリ --pwprompt

で新しいスペースを確保して

pg_ctl -D その新しいディレクトリ start

で動作させてみては ?

957 :NAME IS NULL:2008/10/06(月) 11:26:00 ID:???
>>954
>>956の通りなんだけど、
データベースの場所は、環境変数PG_DATAに設定されていて、
PG_DATAの場所に以前のdbが残ってるってこと。
いらないデータならいったん消してinitdbしなおせばいいし、
場所移したいなら>>956のように新たにinitdbすればい。

PG_DATAはデフォルトだと、、、PG_HOME/dataつまり /usr/local/pgsql/data のままなんじゃないかな?

958 :NAME IS NULL:2008/10/13(月) 23:51:37 ID:fi3Aq2C+
どなたかいらっしゃいましたら
PostgreSQL 7.3について教えていただきたいことがあるのですが、
VACUUM FULLを行い、時間がかかりすぎているため、中断したいのですが
その場合やはり不具合などはおきてしまうのでしょうか?
明日の朝5:00までにシステムを稼動させないといけないため、
あせっております。。
詳しい方いらっしゃいましたら、お願いいたします。

959 :NAME IS NULL:2008/10/14(火) 00:04:45 ID:???
明日の朝5時なら終わるだろ

960 :NAME IS NULL:2008/10/14(火) 00:05:05 ID:???
業務の事を2chで質問とは・・・
せめてMLに投げろよ。
お金を払ってる会社が可哀想です。

961 :NAME IS NULL:2008/10/14(火) 00:07:14 ID:???
しかし一度2chで質問してしまってる以上同じ質問をMLでするのは恥ずかしいな

962 :NAME IS NULL:2008/10/14(火) 00:12:11 ID:???
なーに、PHP MLでは日常茶飯事さ。
あっちをみていて、こっちを見ている人も多いだろうから
まあそういうものと思って優しい人が出てきてくれるだろう。

963 :NAME IS NULL:2008/10/14(火) 00:23:58 ID:???
2chなら一番優しくて>>959だと思うぞ
これ以上優しい回答は出てこんよ多分

964 :NAME IS NULL:2008/10/14(火) 00:47:09 ID:7sacMnBx
958です。
vacuum処理がなんとか終了しました。
10時間以上かかっていたので、同様してしまいました。
お騒がせしまして申し訳ありません。

965 :NAME IS NULL:2008/10/14(火) 00:54:13 ID:???
以下同様。

966 :NAME IS NULL:2008/10/14(火) 01:17:47 ID:???
vacuumってそんなかかるのか

967 :NAME IS NULL:2008/10/14(火) 01:23:06 ID:???
7てフルでレコード多くて相当久しぶりなら掛かる可能性はある
でも毎週やれば長くても数十分で終わるけどね

968 :NAME IS NULL:2008/10/14(火) 01:50:49 ID:???
それにしても、いまさら7.3というのがアレだ。
業務システムだとそうそうバージョンアップできないのは確かだけどさ…

969 :NAME IS NULL:2008/10/14(火) 02:56:05 ID:???
逆に7.3ってことは5年以上データを蓄積しているってことでもあるな

970 :NAME IS NULL:2008/10/14(火) 03:24:45 ID:???
vacuumにそんなに時間がかかるのなら、いっそdumpして新規DBにrestoreしたほうが
早いんじゃないか? もちろん、ストレージが必要になるけど。

971 :NAME IS NULL:2008/10/14(火) 03:33:57 ID:???
鯖立ててもお釣りがくるな。
フォーマットからした方が良いかも。

972 :NAME IS NULL:2008/10/14(火) 03:57:31 ID:???
素直に8.2以上にしなよ

973 :NAME IS NULL:2008/10/14(火) 22:56:41 ID:???
vacuumに10時間かかるDBってどれくらいの規模か
ちょっと知りたい気がする。
どれくらい放置してたのかも。

974 :NAME IS NULL:2008/10/14(火) 23:05:33 ID:???
スペックがしょぼいんじゃないの?
さらにメモリ少なくてスワップしまくりとか。

975 :NAME IS NULL:2008/10/14(火) 23:26:02 ID:???
なおかつ金ケチってIDEのFakeRAIDとかありそうw

976 :NAME IS NULL:2008/10/14(火) 23:37:13 ID:???
vacuum full なら不思議じゃないな。
数百GB/十数億レコードのDBだけど、丸一日かかるよ。

977 :NAME IS NULL:2008/10/14(火) 23:47:59 ID:???
レコードてんこもりだー
何管理してんだろう?postgresqlもがんばれるものだね。

978 :NAME IS NULL:2008/10/15(水) 01:22:01 ID:???
7.4でやってたけど2000万レコードで速度が微妙になりすぎてOracleに変えた

979 :NAME IS NULL:2008/10/15(水) 09:54:05 ID:???
うちはサーバ換えたわw

980 :NAME IS NULL:2008/10/15(水) 20:57:50 ID:???
サーバ換えは簡単にパフォーマンスを上げれるからいいな

981 :NAME IS NULL:2008/10/15(水) 21:46:25 ID:???
サーバスペック上げた方が安くて早いってのは
近年の技術者の技術力低下の原因でもあるんだよな
無駄が多くてもハードとミドルで吸収しちゃうから作るソフトがクソになりやすい
選択肢がSQLチューニングしかないという状況をクリアして経験値積まないといかんよね

982 :NAME IS NULL:2008/10/15(水) 21:59:36 ID:???
同感。DBに限らず言えることだね。

983 :NAME IS NULL:2008/10/15(水) 22:03:43 ID:???
いやぁ、能力の足りない環境で無理しても、テーブル分割、繰り返しフィールド、
事前集計、事前結合が脈絡なく多用される糞設計になるのがオチ。


984 :NAME IS NULL:2008/10/15(水) 22:22:23 ID:HojZLdyd
railsでDBとしてPostgreSQL使っています。
Webアプリにカウンター機能を持たせているのですが、ちょっと疑問に思ったことが
あるので質問させてください。

/app/indexにアクセスがくるとcounter tableのカラムのtodayの値を1増加させるのです
が、増加させる度にHDDにアクセスしているのでしょうか?

頻繁に更新のあるテーブルでもテーブルのレコードの値を変更する度にHDDにアクセスす
るようだと無駄が大きい気がするのですが、PostgreSQLではどのタイミングでHDDにアク
セスするのかご存知の方はおられないでしょうか?

もしおられましたら参考サイト・書籍などを紹介していただけないでしょうか?


985 :NAME IS NULL:2008/10/15(水) 23:40:25 ID:???
起動オプションで-Fをつける。
http://www.postgresql.jp/document/pg834doc/html/app-postgres.html

ただ、チューニングするときは基本実測して、どこがボトルネックなのかを調べてからがいいよ。

986 :NAME IS NULL:2008/10/16(木) 00:18:10 ID:???
>>984
PostgreSQLに限らず、基本的にはDBMSがチェックポイントっていうのを勝手に発行した
タイミングだよ。
タイミングは各DBMSの各バージョンによってそれぞれ変わってくる。
プログラムからDBにINSERTした直後はまだメモリの中。チェックポイントが走って初めて
ディスクに書き込まれる。

ただ、カウンタぐらいならそんな意識しなくても問題ないはず。


987 :NAME IS NULL:2008/10/16(木) 01:41:11 ID:???
ログはその都度書かれると思うぞ

988 :NAME IS NULL:2008/10/16(木) 01:56:32 ID:???
http://www.postgresql.jp/document/pg834doc/html/runtime-config-wal.html#GUC-SYNCHRONOUS-COMMIT
要求からするとトランザクション単位で設定できるこっちの方がいいか。

>>986
postgresqlのデフォルトはそうじゃない

989 :NAME IS NULL:2008/10/16(木) 03:52:07 ID:???
fsync=onならとりあえずディスクにはかかれるんじゃない?
commit_delayとかもあったと思うけど

990 :984:2008/10/16(木) 23:48:24 ID:???
皆さんありがとうございます。

私も自分で調べていて、どのDBでも最初はメモリに更新内容を蓄えておいて
ある瞬間になったらディスクアクセスするというような記述がありました。

DBの内容を変更するために毎回HDDにアクセスするか、メモリに書き込んで
キャッシュしておくかは設定次第ということも分かりました。

さらにはメモリのキャッシュ量まで設定できると知って驚きました。

また何か疑問に思ったことがあれば聞きにきます。

991 :NAME IS NULL:2008/10/17(金) 02:56:29 ID:???
>>990
> 私も自分で調べていて、どのDBでも最初はメモリに更新内容を蓄えておいて
> ある瞬間になったらディスクアクセスするというような記述がありました。

そんなはずは。突然マシンが死んでも、コミットが完了したものについては
ディスクに書き込まれている事を保証する、というのが昔のイメージだった。
だからpostgresqlだってデフォルトでfsyncがonなんだろうし。


992 :NAME IS NULL:2008/10/17(金) 03:46:58 ID:???
レスの内容を読んでないことが丸わかりで困る。
マニュアルじゃなく、その辺のサイトに書いてたことを鵜呑みにするくらいなら
こんなとこに来なくていいのに。

993 :NAME IS NULL:2008/10/17(金) 04:33:41 ID:???
>メモリのキャッシュ量まで設定できると知って驚きました。

驚くなよ
conf見りゃ解るだろ

994 :NAME IS NULL:2008/10/17(金) 17:09:42 ID:???
>>992
2chのレスよりその辺のサイトに書いてあることを信用するというのは
正しい姿勢かもしんまいw

995 :NAME IS NULL:2008/10/18(土) 17:36:30 ID:???
次スレを建てました。

PostgreSQL Part.6
http://pc11.2ch.net/test/read.cgi/db/1224318817/

996 :NAME IS NULL:2008/10/18(土) 17:44:19 ID:???
おつぅめ

997 :NAME IS NULL:2008/10/18(土) 20:42:36 ID:???
みんな1000には興味ないの

998 :NAME IS NULL:2008/10/18(土) 20:50:04 ID:???
気にするスレじゃ無い気がするw

999 :NAME IS NULL:2008/10/18(土) 20:51:09 ID:???
1000なら、8.4が今年中にリリース(`・ω・)

1000 :NAME IS NULL:2008/10/18(土) 21:53:08 ID:???
1000取っておこう

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

300 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)