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)
これかな?