08/05/11 16:40:36 nKIrUfLq
postgresqlをlinuxにインストールしてみましたが、
jdbcがありませんでした。
jdbcのみインストールできるサイトはありませんか？
よろしくお願いいたします。
551:NAME IS NULL
08/05/11 18:12:16 hAgtRqsE
>>550
本家->downloadでDLのページいってみては？
552:NAME IS NULL
08/05/11 18:44:24
複数のサーバに分散させてたアクセスログテーブルを一サーバにまとめる
作業をしてるのだけど、IDカラムをPRIMARY KEYにするために
数字を重ならないように振り直す良い方法ない？
連番である必要はないのだけど、
UPDATE id = nextval('foobar_id_seq');
だとトランザクションが完了までにストレージの容量不足であぼ～ん。
データベースが500Gでストレージ容量が800Gな感じ。
行数はpgAdminの概算で10億のオーダー（実際にもたぶんそんなもん）。
Intel 8コア2Ghz、メモリ6Gで丸一日動かすぐらい以下で終わるとうれしい。
553:NAME IS NULL
08/05/11 19:33:49
>>548
暗号の基礎というのが想像つかないけど、公開鍵暗号とか、ハッシュ関数？AliceとかBobがいて、…みたいなことかな。
よかったらポインタとかキーワードください。
部分一致検索「できない」ところに暗号化する意味があるといえばあると思うんだけど、暗号化されたままのデータに対するプログラムによる処理、という研究領域もあったような。
まだ実用段階ではないはず。
554:NAME IS NULL
08/05/11 20:59:34
>>552
250GBぶん処理 → VACUUM → 残りの250GBを処理
で、750GBぎりぎりに収められるような気はするけど、効率的では無いね。
オリジナルの各サーバからデータをダンプすると思うのだけれど、
そのときについでにIDを再割り振りしてはいかがでしょ？
COPY (SELECT ID + <サーバごとのオフセット>, <ID以外の属性> FROM tbl) TO ...
みたいな。
555:NAME IS NULL
08/05/11 21:49:59
>>554
レスどうもです。
すでにpg_dumpでテーブルを圧縮ダンプしてオリジナルを消してしまって
いるのですが、書き戻しつつまったりやってみます。
スタンドアロンで起動してチョメチョメするとUPDATEがトランザクションを
作らずできるとかあると良かったのですが。
556:NAME IS NULL
08/05/11 22:49:47 nKIrUfLq
>>551
このやり方だとすべてをインストールしなければならないですよね？
jarファイルだけほしいんですが・・
557:NAME IS NULL
08/05/11 23:05:40
>>556
つ 本家 [URLﾘﾝｸ(jdbc.postgresql.org)
558:NAME IS NULL
08/05/12 00:19:43
新しい列を追加してサーバID＋IDカラムを主キーにすれば？
559:NAME IS NULL
08/05/12 02:57:40
>>548
>>534はpostgres標準でカラムごとに暗号化する方法が用意されてるよ
というポインタを出しただけだろう。なんでそんな喧嘩腰なん？
560:NAME IS NULL
08/05/12 13:03:06
>>543
せめてどの列に何のデータが欲しいかくらい書いて下さい。
561:NAME IS NULL
08/05/12 14:25:10
>>560
>>543は質問者への例だよ。
質問者が>>542みたいなこと書くからさ。
562:NAME IS NULL
08/05/12 16:11:58
>>561
ごめんよ('A`)
563:NAME IS NULL
08/05/12 19:38:57
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
08/05/13 23:21:07
Direct I/Oが効くからopen_syncでいいんじゃね?
たまにバグ持ちのOSもいるけど。
565:NAME IS NULL
08/05/14 16:50:51
VACUUM FULLをやるとすごい時間かかると聞いていたけど、3分くらいで終わってしまった。
テーブルは200個くらいで、多いテーブルでもレコード数は20,30万レコードくらい、大半は数千、数万程度
これってだいぶ少ない感じだからかな？それともdumpを戻してからあまりデータが更新されてないから
汚れてないってことで早かったんですかね？
後、VACUUM FULL テーブル名って感じでテーブルのみ指定できるけど、これを
全テーブルやれば、VACUUM FULLやったときと変わらないのでしょうか？
566:NAME IS NULL
08/05/14 19:31:16
>>565
>dumpを戻してからあまりデータが更新されてないから
> 汚れてないってことで早かったんですかね？
> これを全テーブルやれば、VACUUM FULLやったときと変わらないのでしょうか？
いちいちその通りでなにも返す言葉がない
567:NAME IS NULL
08/05/16 22:29:54
sequenceの値を自分で設定することは出来ますか。
今は 1 から始まっているのをたとえば10000から始めたいんですが。
568:NAME IS NULL
08/05/16 22:51:10
URLﾘﾝｸ(ash.jp)
答えを知らない俺がググって10秒で分かる内容を質問する勇気に感心した。
569:567
08/05/16 22:57:55
自己レスです。setval()関数でできるようです。
570:567
08/05/16 22:58:21
>>568
すみません
571:NAME IS NULL
08/05/17 00:28:43
使用環境はXPなんですが
COPYでテーブルのデータを全てCSVに落としたいのですが
文字列が２重引用符で囲まれなくて困っています。
COPYの説明読む限り、デフォルトは２重引用符となっています。
QUOTEで直接指定しても変わりありません。
572:NAME IS NULL
08/05/17 09:40:53
>>571
FORCE QUOTE
573:NAME IS NULL
08/05/17 13:30:17
FORCE QUOTEってカラム指定しないと駄目ですよね？
文字列だけ指定した引用符で囲いたいんですが
単純にQUOTEだとNULL文字だけしか引用符で囲ってくれないんです。
574:NAME IS NULL
08/05/17 13:54:31
文字列型のカラムを全部指定すればいいじゃん。
575:NAME IS NULL
08/05/17 17:56:34
集約関数のパラメータとなるような複数行のデータを表現する式というのはありますか？
こういう感じのことをしたいのですが
SELECT * FROM TABLE1 ORDER BY MAX(COL1,COL2,COL3); // COL1～3のなかで最大の値を取りたい
576:NAME IS NULL
08/05/17 17:57:02 UrIKqt4y
しまった。
習慣でsageてしまった・・・
577:NAME IS NULL
08/05/17 18:58:10
>>575
greatest() かな。max(greatest(col1, col2, col3))
578:NAME IS NULL
08/05/19 20:51:28 KbQaa3g3
2chのような掲示板を作ろうと、以下のテーブル構成を考えています。
この場合、連番はどうやって取るのがスマートでしょうか？
板（板No、･･･）
スレッド（板No、スレッドNo、･･･）
レス（板No、スレッドNo、レスNo、･･･）
板Noはシーケンスでいいとして、スレッドNoとレスNoの取り方で迷っています。
Max(レスNo) + 1で取るのがいいか、発番テーブルを作るのがいいか。
あるいはもっとスマートなやり方があるのでしょうか。
アドバイスお願いします。
579:NAME IS NULL
08/05/19 22:29:57
スレッドも(big)serial型でいいんじゃ？規則正しく連続してる必要ないよね？
insert ～ select ～でいいんじゃない？
発番号テーブルとか作ってわざわざ整合とりにくくする必要性無いと思う
580:NAME IS NULL
08/05/20 01:06:45 yIeco2cc
あいうえお<br><h1>かきくけこ</h1>
というデータが入っていたとしまして、SQLでこのタグ(<>で囲まれている文字列)を省き、
あいうえおかきくけこ
として検索できるようにする方法はありますでしょうか。
もしありましたらご教示いただけますと幸いです。
宜しくお願いします。
581:NAME IS NULL
08/05/20 02:47:41
>>580
> SQLでこのタグ(<>で囲まれている文字列)を省き、
regexp_replace(データ,'<.*?>','','g')
582:NAME IS NULL
08/05/20 09:41:17
取り出してからの切った貼ったですかね。
583:NAME IS NULL
08/05/21 09:35:37 LdhCgnd0
よろしくお願いします。
金額を入れるカラムは、精度の高いnumericを使用した方がよいと聞いたのですが、
マニュアル等で調べたところ、そのカラムに整数しか入らない場合はinteger等で十分のような気がするのですが
この考え方で合っていますでしょうか？
584:NAME IS NULL
08/05/21 09:58:22
10/3*3とか？
585:583
08/05/21 11:52:47
>>584
確かにその場合は小数点があるのでnumericが必要ですよね。
必ず整数しか入らない前提の場合はintegerでも良いと思ってよいでしょうか。
「精度」の意味がよく分かっていないかもしれませんが、
整数しか格納しないのであれば、numericもintegerでも計算で誤差は生まれないと
思っているのですが。。
586:NAME IS NULL
08/05/21 13:33:19
SQLで計算はしないのか？
587:583
08/05/21 17:20:11
>>586
SQLで計算はしないOR計算しても小数点が出ないという前提です。
588:NAME IS NULL
08/05/21 20:30:49
>>583
numericが「何と較べて」精度が高いのか聞かなかった？
真数値： numeric integer
概数値： real float
あと、「精度」といっているのが誤差の少なさなのか
有効数字のことなのか。
「金額～」という文脈で精度のことを言うときは、上記の
真数値である(誤差がない)ことを言う場合が多い。
589:NAME IS NULL
08/05/22 07:29:35
そもそも、通貨って円だけじゃないし
日本でも銭まで必要なこともあるし
そういうのを踏まえて必要かそうでないか判断しては
590:583
08/05/22 10:19:23
>>588,589
レスありがとうございます。
元々、素人DB設計者がnumeric(10,0)としていたので
突っ込んでやりたいなと思って質問しました。
＞numericが「何と較べて」精度が高いのか聞かなかった？
金額の計算をする時、integer等と比較しての話として精度が高いと聞きました。
なので、「精度」は
＞真数値である(誤差がない)ことを言う場合が多い。
こっちのことだと思います。
＞日本でも銭まで必要なこともあるし
情報小出しですいません。
私も、numericを使うことに異論は無いのですが、
もともとのカラムがnumeric(10,0)だったんです。。
「精度が高い」と人から聞いただけで、「精度」の意味も考えずに
numeric型を採用しているDB設計者に対して
「小数以下格納しないならintegerでいいじゃないですか」という理由が欲しかった次第です。
低レベルな話ですごく申し訳ないです。。
591:NAME IS NULL
08/05/22 10:48:29
整数としてしか扱わない、というのなら整数でもいいんじゃない？
金額を扱う場合はnumericと決めている、のならnumericでもいいし。
592:NAME IS NULL
08/05/22 12:10:45
numericだのintegerだの云々言いたい583は、当然
URLﾘﾝｸ(ja.wikipedia.org)
あたりの知識はあるんだよな?
まあ、ヲレはPostgreSQLでnumericがどう実装されているか知らないけどさ。
593:NAME IS NULL
08/05/22 21:03:28
整数を扱うとき、numeric型とinteger 型と選ぶ基準は
扱う桁数でいいだろ。
お金だと桁数10桁で足りない事もあるし、そういうときはnumericでいいんじゃね？
俺は、Java上で金額計算するから格納時には桁数roundしてるから
入れ物さえあれば問題ない。
>>590
逆になんでnumericなのか聞けば？
俺は桁数が分かるという利点でnumericにしてるんだと思うがね。
DBのポータビリティを考えて、もう1層上でテーブル設計してるんじゃないか？
594:NAME IS NULL
08/05/22 21:10:58
>>590
うちも同じようなテーブル設計があったので、直せるところはintにしま
した。物の個数ですらnumericでやってあったから、さらに低レベルかも。
intかbigintの方がコンパクトで高速と思ってます。
595:590
08/05/23 12:41:48
>>591-594
レスありがとうございます。
とりあえず、DB設計者になぜnumericなのか聞いてみた結果
→「これがいいって聞いたから」
あとは愚痴スレ行きます。。
>俺は、Java上で金額計算するから格納時には桁数roundしてるから
>入れ物さえあれば問題ない。
私も同じようにしようと思います。
ご助言いただき、ありがとうございました。
596:NAME IS NULL
08/05/24 07:11:45
>>565
ごめん嘘書いちゃった
テーブル指定無しで実行しないとシステムカタログがvacuumされないらしい
URLﾘﾝｸ(www.thinkit.co.jp)
597:NAME IS NULL
08/05/25 19:07:27
>>596
いや、システムカタログ名を指定すればできるだろう。
VACUUM pg_class;
とか。面倒だから普通は autovacuum に任せるけど。
598:NAME IS NULL
08/05/27 14:05:46 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
08/05/27 14:38:11
ONのあとは結合条件、o.foo LIKE '%'||u.bar||'%'はWHERE句に
600:598
08/05/27 14:43:16 ZU6uB09A
すいません。
↑のでできてました。
結合するテーブルにINSERTするデータが間違ってるだけでした。
お騒がせしました。
601:NAME IS NULL
08/05/29 01:30:00 +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
08/05/29 05:49:30
select文を発行したときと
プログラムからのselect時との
client_encodingの違いを意識してるか？
603:NAME IS NULL
08/05/29 10:42:05
>>601
その<BD><BE><CD>・・・を出力してるのはページャー（more とか lessとか）
そのページャーがその文字コードに対応していない。
ページャーを何とかするか、ページャーにあわせてクライアントエンコードを変更する。
604:NAME IS NULL
08/05/29 21:28:20
どこかにWinでpgAdminからSlony-Iの使い方解説したサイトはないものか
605:NAME IS NULL
08/05/30 10:10:15
HELPでいいやん
606:NAME IS NULL
08/06/02 17:13:40
>>597
いやできない。試しにやってみるとこうなる。
WARNING: skipping "pg_user" --- cannot vacuum indexes, views, or special system tables
autovacuumまかせにできるのは小規模だけだろ。
数GB程度のデータ規模でも、アクセスが少ない時間をねらって
毎日vacuumしないとvacuum時間が長くなって大変。
607:NAME IS NULL
08/06/02 17:30:20
autovacuumを頻繁に行い、一回あたりの時間を短くする
608:NAME IS NULL
08/06/02 17:51:00
>>606
pg_userはVIEWですよ。VACUUMできるわけが無いし、する必要も無い。
あと、最近のバージョンだと、vacuum_cost_delayを調整して
vacuum時間を「長くする」側にチューニングしたほうがよい。
レスポンスに影響が無いなら、時間が延びてもデメリットは無い。
「毎日vacuumしないと」も間違い。テーブルによっては、それこそ数分間隔で
VACUUMが必要な場合もあるし、年単位で十分なテーブルもある。
手作業でチューニングするくらいならば、autovacuumのほうが楽だし効率も良い。
VACUUMの運用法は、ここ数年で大きく変わってきているので、
あまり古い考えにこだわり過ぎないことをお勧めする。
609:NAME IS NULL
08/06/02 18:21:54
特に8.3ではHOTのおかげでvacuumする必要性がだいぶ低くなってきたからねぇ。
610:NAME IS NULL
08/06/02 19:24:19
8.3て、致命的問題なく動いてる？
611:NAME IS NULL
08/06/02 20:04:27
>>608
そっか。確かにpg_typeならvacuumできたわ。
>>607
autovacuumって頻度指定できんの？
612:NAME IS NULL
08/06/02 20:13:45
8.2でautovacuumだけで運用してたらあんまりvacuumされなくて
手動でやるようにしたんだけど。
一日数万件のinsert/deleteがあるのに何日間かvacuumされて
なかったんだよ。んでpgAdminで繋いだらautovacuum設定しろしろうるさい。
してあるのに。
バッチで実行すれば「アクセスが少ない時間帯にvacuumが完了」するように
指定できるし、vacuum実行時間のログもシステム側に残る。
autovacuumが効率よくvacuumかけてくれる事を説明してるURLある？
613:NAME IS NULL
08/06/02 21:07:26
>>611
autovacuum_naptimeで最小間隔の指定は出来るし、
autovacuum_vacuum_thresholdやらautovacuum_analyze_thresholdやら
いろいろ設定可能
>>612
stats_row_level = onにはなっているよね?
614:NAME IS NULL
08/06/02 22:55:08
>>612
そのテーブルだけ pg_autovacuum.vac_base_thresh で設定すると良いかも。
別に、バッチVACUUMとautovacuumは排他じゃないから、
むしろ両方とも設定した方が問題が少ないことが多いかな。
615:NAME IS NULL
08/06/03 02:16:34
今は両方セットしてあるんだけど、とあるテーブルだけ8GBくらいあって
日中にvacuum走ると使い物にならなくなってしまうので、
autovacuumは切ろうかと思ってる。
てか毎日vacuumしてて空き領域が良好な状態だったら
autovacuumは走らないものなの？
616:NAME IS NULL
08/06/03 02:59:46
>>615
とりあえず、autovacuumが行われるタイミングに関しては
URLﾘﾝｸ(search.net-newbie.com)
参照。
617:NAME IS NULL
08/06/03 04:26:12
サンクス
閾値を超えなきゃvacuumされないのね。
とりあえず数万件の削除は日毎バッチで行われていて、
手動バキュームはその直後に行うようになってるから、
よりベターなタイミングっていうのは無いと思うのよ。
とりあえずこのまま行く
618:NAME IS NULL
08/06/03 16:19:23
クライアントからODBCを使ってサーバのデータベースに繋ごうと思って
URLﾘﾝｸ(www.advancesoft.co.jp)
のサイトに記載してある通り、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
08/06/03 16:22:44
>>618
せめてnetstatの結果ぐらい確認しろよ
620:NAME IS NULL
08/06/03 16:53:16
>>619
調べてみたら5432のポートが開いてない感じがしたのですが、
その場合どういった対策をすればいいのでしょうか？
postgresql側での設定が必要なのでしょうか？
宜しくお願い致します。
621:NAME IS NULL
08/06/03 17:13:06
>>620
感じがした、って…オマ…
火壁とかどうなってんの？ Windows知らんから、これ以降は誰か頼む。
622:NAME IS NULL
08/06/03 17:32:40
まず、pgAdminIIIで接続できるか確認してごらん。
つながるならODBCの設定があやしいし、
つながらないならpingとかでネットワークで到達できるかからやってごらん。
623:NAME IS NULL
08/06/03 17:34:24
>>622
そんなことせんでも telnet で 5432 に繋げればすぐ分かる。
624:NAME IS NULL
08/06/03 17:58:57
pgAdminIII使ったほうがあとあと役に立つと思ったんだけどな。
625:NAME IS NULL
08/06/03 18:57:11
>>621-624
ありがとうございます。
pingは無事に到達します。
Windows 2000 Serverにファイアーウォールはないと思うんで特に設定はしていません。
とりあえず今は触れる環境にないので、明日もう少し試してみます。
626:NAME IS NULL
08/06/03 19:04:03
>>625
お前が"postgresql ポート 設定"でぐぐることすらできないのと、
telnet foobar 5432すらできない知能なのは良くわかったから、
きちんとお勉強してくるまで出入り禁止。
627:NAME IS NULL
08/06/03 20:19:57
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
08/06/03 20:26:08
>>627
開いてない感じがしただけで
開いてないとは誰も言っていない罠ｗｗｗ
>>625
ま、実際にLISTENポートとしてリストされなかったなら、
設定が悪いだけだから、見直して再設定すればいい。
629:NAME IS NULL
08/06/03 20:28:37
馬鹿は放置しとけよ…
630:NAME IS NULL
08/06/03 20:46:21
feelingで話を進めた段階でアウトです。
分からない事は分からない。
それを素直に出せないのは、
眼鏡をかけた新人の女の子までしか許されません。
631:NAME IS NULL
08/06/03 21:05:04
postgres.confのlistenだろ
632:NAME IS NULL
08/06/03 21:14:53
>>628
しまった！＞＜
633:NAME IS NULL
08/06/03 21:21:02
>>631
別のポート番号にしたいとき、そこ変えて、service postgresql startとやっても
反映されなくてハマったよー
634:NAME IS NULL
08/06/04 03:02:48
>>615
>>612の通りだ。
pg_autovacuumテーブルでそのテーブだけ除外してやんな。
で、夜間にvacuumすればよろし。
635:NAME IS NULL
08/06/04 03:04:30
>>634
ミスったｗ
>>615 → >>614
吊ってくる
636:NAME IS NULL
08/06/04 11:58:40
ちょっと質問させてください。
インデックスを複数同時に張るのって、１つ張り×複数とは別のときに効果を発揮する……のでしょうか？
前任者が張りまくっていたものを整理しているのですが、どうなんだろうと思いまして。
１．id, name, dateが指定されたインデックス
２．nameのみが指定されたインデックス
３．nameがインデックス指定＋where id=10 と記述
が存在。
１は、その３つを同時にwhere使用する場合にしか使われない？ それともidだけをwhere指定する場合でも使ってくれるのでしょうか？
教えて頂ければありがたいです。
637:NAME IS NULL
08/06/04 12:02:19
aというカラムに「テスト1 テスト2 テスト3」や「テスト1 テスト3」、「テスト2 テスト3」といったようにスペース区切りでキーワードが入っていたとして、条件をテスト1もしくはテスト3に設定し、各種レコードでヒット数を表示するようなことは不可能でしょうか。
本条件の場合、はじめのレコードはヒット数2、2番目は2、3番目は1となれば期待通りとなります。
不可能かとは思いますが、もしもやり方がありましたらご教示いただけますと幸いです。
宜しくお願いいたします。
638:NAME IS NULL
08/06/04 13:37:07
>>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
08/06/04 13:44:28
>>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
08/06/04 13:54:58
ん？
カラム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
08/06/04 14:08:09
>>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
08/06/04 16:22:48
>>639-641
ご教示感謝です。
641さんのSQLでうまくいきましたので、こちらを使用させていただきました。
本当にありがとうござした。
643:NAME IS NULL
08/06/04 16:56:29
分離した上で正規化したほうがいいと思うけど
644:NAME IS NULL
08/06/04 17:25:55
実際はキーワード羅列なんじゃなくて商品説明文とかなんじゃないの？
645:sage
08/06/04 22:28:25
>>610
8.3.1、キャスト問題でなかなか8.1からバージョンアップに踏み切れない
状態です。うち、意外に日付や数値の自動キャストに頼ってる場所があった。
もう8.3運用してる人って居るのかなあ？
646:NAME IS NULL
08/06/05 03:18:56
してるよ
というかDBは8.2だったんだけどjdbcドライバで8.3を
使っちゃって自動キャストで引っかかった。
日付で検索したときに条件に引っかからないだけだったから
大して実害なかったけど。
647:NAME IS NULL
08/06/05 08:20:32
>> 645
数値はともかく、日付の自動キャストって怖くない?
日付のフォーマット書式って、環境依存だったような。
うちはPreparedStatementを使ってた関係で、
既に型チェックが厳密だったので、特に問題なく8.3に移行できました。
648:NAME IS NULL
08/06/05 10:42:17
>>636>>640
ご教示ありがとうございました、理解出来ました。
ざっと見8.1からっぽかったですが（これは『個別に貼ってあっても見る』の方かも？）、
ちょっと詳しく調べる時間が無くて提示出来ずに申し訳ないです。
複数インデックスが多い割には何も考えてないSQL文だらけだったので、ちょっと書き換えてきます……。
本当にありがとうございました。
649:NAME IS NULL
08/06/05 19:03:47
うちもPreparedStatement限定だけど
日付をsetString()してた
650:NAME IS NULL
08/06/05 19:07:56
>>640
2番目は駄目だと思うな。複数のカラムを組み合わせてハッシュコードを
作るわけだから、順序入れ替えをOKにしたら偉い数のインデックスを
つくらにゃいけなくなる。少なくともOracleは駄目だ。
だからApache TorqueみたいにWHERE句の順序を入れ替えられない
ORMが嫌われてたんだし。
651:NAME IS NULL
08/06/05 19:29:59
>>650
8.1.11でexplainで確認したら
>>640のパターンは最後のも含めて
全部インデックススキャンになったよ。
652:640
08/06/05 19:55:18
>>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
08/06/05 23:26:11
>>650
芸術的な妄想しったかw
654:NAME IS NULL
08/06/06 05:33:11
>>653
昔のOracleがそうだったいうだけで今は違うみたいだね
ここには順序も入れ替えるなと書いてある
URLﾘﾝｸ(oracle.se-free.com)
torqueでwhere句入れ替えられない事に対する文句は昔MLかなんかで見た。
655:NAME IS NULL
08/06/06 07:17:44
>>654
いやいやいや、そんなこと書いてないw
656:NAME IS NULL
08/06/06 07:25:56
インデックスを「使うこと」はできたとしても、
その「効率」がだいぶ違うことには注意が必要ですよ。
なんにせよ、Bitmap Index Scan は結構なアドバンテージだと思われ。
657:NAME IS NULL
08/06/06 07:54:24
>>655
突っかかりたいだけで日本語も読めないのか
「● 複合INDEXは先頭列から指定しないと、INDEXが使用されない」
URLﾘﾝｸ(www.geocities.jp)
--８．複合インデックスの場合に、列の順粕ﾔを間違えている
col_1, col_2, col_3 に対して複合インデックスが張られているとします。
その場合、条件指定の順番が重要です。
まあpostgresには関係無い話みたいだし悪かったな
658:NAME IS NULL
08/06/06 11:49:08
pgpoolを止めずにpgpoolの設定ファイルの値を変更することってできますか？
知っている方いれば、コマンド教えてください！
659:652
08/06/06 14:39:23
出力される実行計画も同じですし、実行時間もほぼ同じですので
使う事ができるのではなく、オプティマイザが等しく扱ってるように見えます。
(３回ずつ実行してみました)
・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
08/06/06 17:29:56
>>658
設定の項目によるんじゃない？
項目によっては要pgpool再起動
661:NAME IS NULL
08/06/06 18:23:18
indexの順序が関係あるのはOracleのルールベースで
インデックス貼ってた時までだよ。10gでも設定することは
できるけどもうサポートされてない
URLﾘﾝｸ(www.shift-the-oracle.com)
662:NAME IS NULL
08/06/06 18:30:27 LCupMW8E
どなたか教えてください
トリガで特定のカラムの値が任意の条件を満たす場合のみトリガを発動って出来ますか？
例えば、
status というカラムが 0 という値にupdateされた場合のみトリガ発動
みたいなことをしたいんです
可能なら具体的な設定方法をご教授下さい
663:NAME IS NULL
08/06/06 18:31:47
教授 じゃなく 教示でした。。
664:NAME IS NULL
08/06/06 19:04:55
>>662
0という値以外にアップデートされたときは何もせずに終わったらよくない？
トリガが実行されることのコストを気にしてるのかな。
665:NAME IS NULL
08/06/06 19:54:05
>>647
たしかにまずいですよね。substr(日付)とやってる処理があって、いま
手直ししてます。ぜんぜん意識してなかったです。。
666:NAME IS NULL
08/06/07 02:50:25
>>659
その程度の最適化は今時どんなDBMSでもやってくれるよ。
同じで当然。
667:NAME IS NULL
08/06/07 03:15:17
>>666
流れが読めない人だなあ
668:NAME IS NULL
08/06/11 15:56:27
select 文を書く時みなさんはどちらを使いますか？
またその理由を教えてもらえると助かります。
ちなみに自分は①派です。
①select column from table where integer = 1;
②select column from table where integer = '1';
669:NAME IS NULL
08/06/11 16:45:08
スクリプトの人はわからんが、Cやってる人なら文字列と数値を
ごっちゃにするのは嫌うんじゃ
670:NAME IS NULL
08/06/11 17:02:46
>>668
明確に違うものをなぜ同一視する。
文字列である数字と、数値を表す数字では、意味が違う。
671:NAME IS NULL
08/06/11 18:10:46
>>668
② 昔はこれしかなかった。
672:NAME IS NULL
08/06/11 19:21:42
そういえば、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
08/06/11 22:59:50
いろいろレスありがとうございます。
自分は>>669さんと同意見なんですが、
絶対 '1' にしろという人が身近に入るもので気になりました。
あと>>671さんの意見でなんとなく理由がわかりました。
674:NAME IS NULL
08/06/12 06:06:46
暗黙の型変換が行われると速度が遅くなるから
元のカラムの型がintなら1を使うべきだと思ってたんだけど
そう単純な話でもないんだな
675:NAME IS NULL
08/06/12 07:01:53
リテラルであれば別に型変換があっても実行速度は変わらんしな。
676:NAME IS NULL
08/06/12 07:56:21
>>671
私はORACLEのバージョン3から使ってますが、当時から
数値はシングルクォーツなしで参照できたが・・・
677:NAME IS NULL
08/06/12 10:15:58
>>676
私もその少し前からだと思う。マニュアルでは
WHERE DEPTNO = 30 であるのに 処理系では
WHERE DEPNTO = '30' でないとエラーになった記憶がある。
それで '30' とする習慣になってしまった。
もしかして、私の勘違いだったのかな。
678:NAME IS NULL
08/06/12 13:21:33 dWhU52qw
PostgreSQL 8.3.3, 8.2.9, 8.1.13, 8.0.17, 7.4.21
679:NAME IS NULL
08/06/12 15:23:39 eu0D2QJA
DB２台で冗長構成にしたいのだが、
pg_poolはシーケンスの整合性を取る場合にはテーブルロックが必要なのね。
テーブルロックしない方法は何か無いかしら？
Slony-IIとかpgClusterも同じでしょうか？
難しいなら障害時にDB1からDB2に自動的に切り替わらるといった障害耐性が
無くてもよいかな。単純にレプリケーションが取れていれば。
680:NAME IS NULL
08/06/12 19:17:16
>>677
そのカラムがvarcharで定義されてたんじゃなくて？
681:NAME IS NULL
08/06/12 21:59:56
>>679
drbdとか使ってミラーリングしとくとか
自動で切り替わらなくていいならPITRでリモートにバックアップとか
682:NAME IS NULL
08/06/13 05:58:44
>>679
Slony-I ならテーブルロックしない。(-IIはリリースされてないよ)
pgCluster は、そもそも更新性能が 1/10 になるという噂もあるので微妙。
冗長化だけで良いなら、>>681のとおり、warm-standbyかDRBDが良いかも。
683:NAME IS NULL
08/06/13 15:17:28
ここで愚痴ってもしょうがないけど･･･
signed/unsigned修飾子とtinyint型がほしいorz
今時誤差の範囲かもしれないけど貧乏症なので
smallintだと入らないけどunsigned smallintなら入りきる時とか
tinyintで十分な時とか悔しくてしょうがないんだ
684:NAME IS NULL
08/06/13 18:17:27
>>683
DBの実装はよくわからないけどC言語の時は、
shortで宣言してもCPU内ではintで確保して半分未使用になるだけなので
実は速度はintの方が早いっていうのがあったよ。
大量のデータを構造体にしてネットワークでやりとりするときは
packed宣言すればデータ量を節約することはできたけど。
構造体へのポインタ(アドレス)からsizeof(構造体)分をbyte[]にキャスト
して使うような太古の作り方の話だけどね。
685:NAME IS NULL
08/06/13 19:27:54
今でも一番パフォーマンスが出るのはintだと書かれているよ
686:NAME IS NULL
08/06/13 19:30:08
URLﾘﾝｸ(www.postgresql.jp)
参考までに。
687:NAME IS NULL
08/06/13 19:39:55
>>684
C言語は、intがその処理系で一番パフォーマンスが出るように、と選ばれます
なのでintが速いのは当然です。
688:NAME IS NULL
08/06/13 20:11:32
>>683
さぁ、ユーザ定義型を自作するんだ！
689:NAME IS NULL
08/06/13 23:15:36
>>684
DBはそのネットワークと似たようなもんだよ。結局ディスクIOが最大のネックだから。
何億レコードにもなるようなテーブルは1byteでも減らしたくなるのが人情。
690:NAME IS NULL
08/06/14 00:11:27
>>686
サイズと性能の釣り合いがとれてる（=コストパフォーマンスがいい?)のはintだと
書かれているけど、小さいサイズで構わないときにsmallintよりintの方が
速いとはかかれてないね。
>>689
ごもっともで
691:NAME IS NULL
08/06/14 00:18:06
みんなポスグレのレプリケーション何使ってる？
692:NAME IS NULL
08/06/14 00:49:03
レプリケが必要なプロジェクトではポスグレなんか使わない。
１日１，２回のpg_dump
693:NAME IS NULL
08/06/14 20:34:22
普通はSlony、同期が必要ならpgpool、
バックアップ用ならwarm-standbyで鉄板じゃないの。
694:NAME IS NULL
08/06/15 00:45:18
>>690
なるほどなるほど。確かに。
では、たとえばsmallintのほうがintよりも速い場合、以下のような記述をするでしょうか？
> smallint型は一般的にディスク容量に制限が付いている場合にのみ使用します。
~~~~
どうせならこう書きそうじゃないですか？
> smallint型に収まるデータを扱う場合はsmallintを使用することを推奨します。
> なぜならずっと速いからです。
あえて先の記述をするということは対して速度に差がないのであろうと想像します。
実際に測定するのが手っ取り早いんですけど、ドキュメントから読み取れることも多いと思います。
695:NAME IS NULL
08/06/15 01:13:31
キモイキモイナニモカモキモイ
696:NAME IS NULL
08/06/15 01:48:21
>>694
状況によるだろ。
100GBのテーブルと200GBのテーブルのfull scanを比較したら小さい方が速いだろうし。
697:NAME IS NULL
08/06/15 09:11:54
>>691
うちはpgpool II 使ってます。ハード障害対策で使ってるんだけど、
意外にハード障害が起こらなくて、今のトコ手間だけ２倍以上な印象。
２重化してるせいで、大量更新集中時の読み出し処理とかは、片側から
読むようにしたりとか、変なコツが必要だったりする。
698:NAME IS NULL
08/06/15 13:40:18
>>693
>>697
やっぱりpgpoolが多いのですねぇ。。。うちはPGclusterのロードバランシング機能はずした状態で使ってんだけど
ほかにそういう人いないかな。選んだ理由はデータ復旧がコマンド一発で楽だからなんだけど。
699:NAME IS NULL
08/06/15 23:02:13
今PC用でpostgresでデータベースのみ使っています。
今度携帯用データベース作ろうとしたとき
一緒にするか分けるかどっちがいいんですかね…？
mysqlとpostgresを併用するのは速度的にはどうなんでしょ？
700:NAME IS NULL
08/06/16 02:08:25 UXZw8p6G
質問させてください
vistaにposgreをインストールできたのですが、postgresとつけたアカウントのパスワードで、データベースpostgresにアクセスしようとすると
フリーズしてしまいます。
どうすればvistaでフリーズしないで使えるようになるのでしょうか？
701:NAME IS NULL
08/06/16 02:36:58
>>700
フリーズってPC(OS)丸ごと? クライアントアプリだけ?
アクセスしようとしたクライアントはナニ?
postgres以外のアカウントだとどぉう?
っていうか、posgreってなんだよ。
702:NAME IS NULL
08/06/16 09:29:14
>>699
別にPostgreSQLで困りはしないだろ。
703:NAME IS NULL
08/06/16 11:34:23
>>699
どっちでもいいので、DBは統一しておいた方が楽。
特にこだわりがなければPostgreSQLでいいでしょう。
704:NAME IS NULL
08/06/16 15:32:22
URLﾘﾝｸ(www.postgresql.jp)落ちてる？
705:NAME IS NULL
08/06/16 16:38:53
>>704
そうみたい
706:NAME IS NULL
08/06/16 16:40:42
>>699
併用しても問題ないけど、管理の手間を考えたらposgres一本の方がいいよ。
キャッシュの割り当てとかも一括だし。運用に携わる人はpostgresもmysqlも
どっちもプロフェッショナルなの？両方混ぜると似たようなコマンドで混乱すると思うんだけど。
あとマスタとか共通利用できないの？できるんだったらマスタテーブル一個の方が
更新も楽だしいいと思うけど。ものすごい負荷の高いシステムで将来的に
DBをわける可能性が大きいなら、今からインスタンスを分けておく意味も
あるかもしれない。
707:NAME IS NULL
08/06/16 23:12:40
もし分けるとしても同じDBMSのほうがよさげに思う。
同じシステムのPC版、携帯版という違いであれば同じDBMSにしといたほうがいいよ。
708:700
08/06/16 23:47:37
>>701
DOSからアクセスしたのですが、passを入力してenter押すとOSごとフリーズしてしまいます。
709:NAME IS NULL
08/06/16 23:49:20
>>708
ローカルマシンのPostgreSQLインスタンスにpsqlで接続しようとしたらOSごとフリーズってことですか？
710:699
08/06/16 23:56:17
>>702、703、706、707
みなさん、ありがとうございます。
postgresで統一したいと思います。
PCと携帯で違うデータを見せたいのですが
マスタテーブルも一つにした方が良さそうですね・・・。
ありがとうございました。
711:NAME IS NULL
08/06/17 10:26:27
統一にしても、DBクラスタを別にしてPostgreSQLを複数起動するとか、
DBを別にするとか、スキーマでわけるか、テーブルで分けるか、キーで分けるか、
712:700
08/06/17 17:27:59
>>709
そうです、ネットで調べた通りにやったのですが無理でした。
713:NAME IS NULL
08/06/17 17:47:13
>>712
まずメモリをチェックしなさい。
次にＨＤＤをチェックしなさい。
Ｌｉｎｕｘ(Unix)ならこんな事で落ちない。
うんともすんとも言わない。メッセージが出ない。
保護違反とかのエラーは全てメモリエラーと思っていい。
714:NAME IS NULL
08/06/17 18:20:27
メモリエラーの結果、誤動作して保護違反ということはあるかもしれないが
保護違反とメモリエラーとは直接の関係は無い。
715:NAME IS NULL
08/06/17 18:25:12
保護違反じゃなくて、理由のわからないフリーズはハードを疑ったほうがいいけどな。
フリーズってのが全体が止まるのならな。
716:NAME IS NULL
08/06/17 19:18:07
ハードだろうね。
保護違反ならメッセージ出るか再起動するかする
717:700
08/06/18 00:44:28
ということは、自分のパソコンを修理に出すべきなんでしょうか？
普通に使っている分には、まずフリーズしないのですが・・・SP1入れようとするとフリーズしますが・・・。
718:NAME IS NULL
08/06/18 01:32:15
ノートで熱暴走してるとか
ないか
719:NAME IS NULL
08/06/18 04:34:25
>>717
だめじゃん
720:NAME IS NULL
08/06/18 10:21:41
アンチウィルスソフトで引っかかってUAEの警告だそうとしてるだけとか
ないか
pgAdminではつなげないの？
721:NAME IS NULL
08/06/19 00:15:18
sp1入れてフリーズって普通じゃないよな。
ｐｃ新規購入をお勧めする。
722:NAME IS NULL
08/06/19 00:24:28
PC買い替える前にOS再インストールだな。
723:NAME IS NULL
08/06/19 01:34:49
の前にH/Wいろいろチェック
724:NAME IS NULL
08/06/20 11:25:00
Explaining Explain日本語版ドラフト ? NPO法人 日本PostgreSQLユーザ会
URLﾘﾝｸ(www.postgresql.jp)
にある Explaining Explain の日本語版読んでみたいんですが、
パーマリンクの変更があった影響なのか
単にもうファイルがないのか読めないでおります。
どなたかファイル持ってる方いらっしゃればどこかにあげていただけないでしょうか？
JPUG公式ぽいんですが、コメントのSPAM荒れっぷりを見てもメンテされてない可能性があるので
こちらにきてみました。
コリコリにDBチューニングしたいわけではなくて、SQLかく時にある
ちょっとした迷い（結果同じだけどどっちの書き方がいいかな？）
をクリアする助けになればなぁと思ってる感じです。
725:NAME IS NULL
08/06/20 12:05:19
>>724
困った時の、Web Archive
URLﾘﾝｸ(web.archive.org)
726:724
08/06/20 12:59:02
ぐぁ・・・基本的なことが抜けておりました。
大感謝です！
727:NAME IS NULL
08/06/28 23:16:56
すみません
質問させて下さい。
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
08/06/28 23:32:34
上げてみました
729:NAME IS NULL
08/06/28 23:45:40
うちのWinXPでは実行ファイルはC:にインストールしてあって、
-Dで指定するデータ領域は別のドライブにしているけど、普通に動いてる。
730:NAME IS NULL
08/06/28 23:55:33
>>729さん
ありがとうございます。
多分initdb.exeで -D 以降に移動させたいファイルパスを指定
してあげればいいのかなと思うのですが、initdb.exeの使い方が
いまいちわかりません・・・。
新規にデータ領域を作成して、そこに既存のdataフォルダをコピー
するような感じでいけるんでしょうか？
initdb.exeはコマンドプロンプトで実行するのでしょうか？
もしわかれば教えてください。
宜しくお願い致します。
731:NAME IS NULL
08/06/29 00:06:36
既存のデータ領域があるなら丸ごとコピーして-Dでそっちを指すようにすれば動くんじゃないかな。
initdb はコマンドプロンプトで --help とかつけて動かせば説明が出るけど、
>>1のドキュメントを読んだ方が良いかも。
732:NAME IS NULL
08/06/29 01:13:30
>>731
アドバイスありがとうございます。
取り合えず調べて、空の別ドライブのdataフォルダにinitdbの実行し
成功するまでは出来ました。
その後、新規dataフォルダを既存のdataフォルダに上書きして、
サービスの実行・・・・・・起動不可
再度、空のdataフォルダを作成して、initdbを実行。
今度はそのままサービスの起動・・・・・・起動不可
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pgsql-8.3\ImagePath
の値はinitdbの指定パスと同じにしているのですが、他に設定
が足らないのでしょうか？
733:NAME IS NULL
08/06/29 01:34:59
>>732
コントロールパネル -> コンピュータの管理 -> サービス を開いて
PostgreSQLのプロパティを見て、[全般]タブの「実行ファイルパス」が
レジストリと同じ値になっているか確認して味噌。
っていうか、レジストリを直接弄るってはじめて知った。
scコマンドを使うものばかりだと...。
734:NAME IS NULL
08/06/29 01:37:19
システムのログでも見れば。
735:NAME IS NULL
08/06/29 02:05:45 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
08/06/29 02:28:40
>>735
元Unix系でWindowsに移植されると、あるのにNo such file... って出て悩ませるときがあるよねぇ。
ユーザpostgresに読み取りアクセス権限が設定されていないとか。
そんときゃpostgresql.confだけじゃなくて、/dateディレクトリ下の全てのファイルとディレクトリを
設定し直さなきゃだが?
737:NAME IS NULL
08/06/29 11:49:56
psql (PostgreSQL) 8.2.4 を使ってますが、バックアップとリストアをしようとしています。
pg_dumpallでファイルにバックアップした後リストアすると文字化けが発生してしまいます。
登録データーがSJISなのですが、OSはUTF-8 CJKになってる為と思われますが文字化けを回避する方法はありますでしょうか。
また、上記状態でpg_dumpallしてあるファイルを文字化け無しにリストアする事は出来ないでしょうか。
宜しくおねがいします。
738:NAME IS NULL
08/06/29 11:55:18
つ nkf
バックアップ前・後のDBの文字コードは同じ？
FTPとかを利用してファイル移動とかする際に
文字化けが入ってしまう可能性は無い？
使用しているOSは？
もうちょっと情報プリーズ
739:737
08/06/29 12:21:50
>>738
早速のご回答、ありがとうございます。
バックアップ前・後のDBの文字コードは同じです。
ｐｏｓｔｇｒｅｓはfedora上で動いており、XPからwinSCPとputtyを使ってアクセスしてますが
バックアップしておいた時点のDBを再現したいので最悪はputtyでログインして
fedoraのディスクにそのままバックアップとリストアが出来れば良いです。
出来ればwinscpでローカルのXPにバックアップ出来れば嬉しいですが…
nkf、ググって見ました。pg_dumpallしてしまったファイルに適用しても元に戻せるのでしょうか。ちょっとやってみます。
740:NAME IS NULL
08/06/29 12:24:11
>>738
>FTPとかを利用してファイル移動とかする際に
>文字化けが入ってしまう可能性は無い？
記憶が曖昧なのですが、fedora上でputtyでログインし
バックアップとリストアしても文字化けした様に思います。
741:NAME IS NULL
08/06/29 12:34:07
× 記憶が曖昧なのですが、fedora上でputtyでログインし
○ 記憶が曖昧なのですが、fedoraにputtyでログインし
742:NAME IS NULL
08/06/29 13:06:59
>> 737
そもそもDB作るときに文字コード何にした？
$ psql -U postgres -l
List of databases
Name | Owner | Encoding
------------------+-----------+----------
***** | ******** | UTF8
この一番右のEncodingの値
743:NAME IS NULL
08/06/29 13:21:10
>>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
08/06/29 13:42:39
>>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
08/06/29 14:38:36
>>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
08/06/29 14:52:45
>>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
08/06/29 16:55:09
>>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
08/06/29 17:45:07
>>747
>多種類の文字コードだと出力出来ないのでしょうか。
DBごとにdumpしてみたらどうなのさ？ もうちょと自分で思考錯誤しる。
749:NAME IS NULL
08/06/29 19:03:19
もしかして: 試行錯誤
750:737
08/06/30 07:50:38
>>748
DB毎にdumpしてみましたが文字化けが発生している様でした。
別サーバーを立てて文字化け部分を切り出そうとしている所ですが
昨日の初書き込みから、お蔭様でだいぶ進展した感じです。
暫く自分でやって見てまた判らない事がありましたら質問させて頂きます。
本当にありがとうございました。
751:NAME IS NULL
08/06/30 16:37:15
環境変数のPGCLIENTENCODINGとか？
752:NAME IS NULL
08/06/30 16:40:40
DB毎に文字化けってどういうこと？
例えばEUC_JPで出したものをEUC_JPとして見ようとしても化けてるの？
文字化けしてると勘違いしてるだけじゃね？
753:NAME IS NULL
08/06/30 18:37:06
DBをASCIIでつくっちゃったんならクライアントの
文字列をそのままバイト配列として格納してくれるんだっけ？
新しいDBをUTFで作ってプログラム組んでSELECT->INSERTしたほうが
早そうだけなあ
754:NAME IS NULL
08/06/30 23:38:49
現在レンタルサーバを借りているのですが、データベースのバックアップをしようと思い、pg_dumpをした所「WARNING: ignoring unconvertible UTF-8 character」と言ったメッセージが表示されました。
ただ一応ダンプデータは作られたので、そのデータを元に復旧を試みた所、一部データが欠落していました。
ググッてみて文字変換の問題のような気がしたのですが、ユーザーレベルで解決する方法が分かりませんでした。
URLﾘﾝｸ(www.google.com)
その為何か良い手ががございましたら、アドバイスをいただければと思います。
よろしくお願いします。
755:NAME IS NULL
08/07/01 02:01:50
>>754
DBがUTF-8でシェルのLANGがUTF-8じゃないとかじゃないの？
繰り返しになるけど、
環境変数のPGCLIENTENCODINGとか？
756:NAME IS NULL
08/07/01 15:37:39
PostgreSQLって基幹業務でも安心して使えますか？
757:NAME IS NULL
08/07/01 16:10:24
>>756
管理者が詳しければ安心
管理者が詳しくなければどのRDBMS使っても安心できない。
758:NAME IS NULL
08/07/01 16:14:23
DB本体はともかく、基幹業務となるとバックアップとレプリケーションかなぁ。
一番の問題はPostgreSQLを扱えるSIの質と数だろうけど。
759:NAME IS NULL
08/07/01 16:30:12
1万ユーザーで同時使用は1000人くらいですが
パフォーマンス的には問題ないでしょうか？
760:NAME IS NULL
08/07/01 16:37:14
使用状況や環境にもよるでしょ。
761:NAME IS NULL
08/07/01 16:43:03
具体的なトランザクション数とまでは言わないけれど、一口に同時使用が
1000人といっても、それはフロント部分の作りに大きく依存するでそ。
それだけじゃなんとも言えない罠。ただ、今現在そのシステムがOracle等で
動いているのなら、パフォーマンス的にはPostgreSQLでも動くはず
というのはいえる。
762:NAME IS NULL
08/07/01 23:30:29
>>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
08/07/01 23:34:10
>>762の上から8行目は文字コード0xE28094のUTFの文字を貼り付けたのですが、文字化けしてしまいました。
多分pg_dumpでも同じようなことがおきてWARNING表示になったのだと思います。
764:NAME IS NULL
08/07/01 23:53:51
>>762
自分の環境変数は自分で変えられるよ
export PGCLIENTENCODING=UTF-8
ってやってからpg_dumpしよう
765:NAME IS NULL
08/07/01 23:58:16
連投ごめんです。
記憶違いでなければ、PGCLIENTENCODINGが設定されていない場合はLANGが使用されたと思うよ。
んで、ダンプファイルを突っ込むときにエンコード周りのエラーが出た場合なんだけど、
ダンプファイルの中の set client_encoding という行がある場合はそれが
優先されているので、そこがおかしくないかチェックしてみるとよいです。
766:NAME IS NULL
08/07/02 00:15:01
>>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
08/07/02 09:25:32
pg_dumpに-eって無かったっけ？
768:NAME IS NULL
08/07/02 10:01:57
-E または, --encoding= でしょ、あるよ。
769:737
08/07/02 11:28:22
>>751
今回は関係なかった様です。ありがとうございました。
>>752
EUC_JPのＤＢは化けてませんでした。
と言うか、SQL_ASCIIのDBを削除する為に仮に作っただけだったので、データーが殆ど入ってなかったと言うのもありますが。
追伸
SJISの文字化けで質問していた者です。他の業務が入ってしまい追試が遅くなりました。
色々やってみましたが、ＤＢから携帯からのメールのみ削除してバックアップした所文字化けがなくなりました。
携帯の特殊文字に関連しているのかも知れません。とりあえずプログラマにその旨を伝え、対応してもらう事になりました。
時間が取れたらこちらでも詳しく調べようと思います。
ご教示頂いた皆様、本当にありがとうございました。
追伸２
４GのメモリとQuadのマザー買っちゃいました。素人が試行錯誤するには反応が早くて良いですね。
770:NAME IS NULL
08/07/02 21:56:28
>>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のマニュアルは下記を参考にしました。
URLﾘﾝｸ(www.postgresql.jp)
URLﾘﾝｸ(www.postgresql.jp)
771:NAME IS NULL
08/07/02 23:37:35
>>765
PGCLIENTENCODINGが設定されてない場合の補足ですが、
下記のサイトに以下の記載がありました。
> -E encoding
> --encoding=encoding
> 指定した文字セット符号化方式でダンプを作成します。デフォルトでは、ダンプはデータベースの符号化方式で作成されます
> （PGCLIENTENCODING環境変数を好みのダンプ時の符号化方式に設定することで、同じ結果を得ることができます）。
URLﾘﾝｸ(www.postgresql.jp)
この文章の「デフォルトでは、ダンプはデータベースの符号化方式で作成されます」というのが、
>>770のEncodingの部分を指していると思われます。
772:NAME IS NULL
08/07/03 02:08:24
テーブルに登録している「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
08/07/03 03:31:45
>>772
フロントエンド(psqlなりプログラミング言語なり)がエスケープする分とlikeがエスケープする分が必要。
folderPath like 'c:\\\\%'
774:NAME IS NULL
08/07/03 09:53:15
c:\% がOKなのは、 c:\% → c:% → c:% だからだな。
775:NAME IS NULL
08/07/04 14:49:20 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
08/07/04 15:43:53
phpinfoに出てこないんじゃ、そもそも無理でしょ。
PostgreSQLが使えるようにビルドしなおすか、
ビルドしたバイナリ持ってくるしかない。
777:776
08/07/04 15:49:51
ちょっとググってみたけど、extension_dirは設定してる？
そして、extension_dir にちゃんと php_pgsql.dll は入ってる？
778:NAME IS NULL
08/07/04 16:09:43
>>775
phpinfo();
でpgsqlのセクションが表示されなければ
たぶん、extensions_dirの設定ミス。
つか、Win32版のバイナリなら再コンパイルとか不要で、
ほとんどのオプションはphp.iniの設定変更のみで使用できる。
779:NAME IS NULL
08/07/04 18:49:06
>>775
Bug #44905 PHP 5.2.6 fails to load PostgreSQL related libraries
URLﾘﾝｸ(bugs.php.net)
これかな?