07/12/02 00:41:47 Q5JHapW8
>>1
乙！ 盛り上がっていきましょうw
3:NAME IS NULL
07/12/02 13:35:21
もうpostgresSQLが入ってるサーバを全部ぶっ壊したい
4:NAME IS NULL
07/12/04 02:25:53
ネタがないので、PostgreSQL関連の過去ログでもはっとく。
【Windows】 PostgreSQL8 Part.1 【対応】 ｽﾚﾘﾝｸ(db板)
■ PostgreSQLのことならここで聞け ■ ｽﾚﾘﾝｸ(db板)
■ PostgreSQLのことならここで聞け ■ ｽﾚﾘﾝｸ(db板)
PostgresSQLについて語ろう ｽﾚﾘﾝｸ(db板)
PostgreSQLについて語ろう where OID=2::oid ｽﾚﾘﾝｸ(db板)
PostgreSQL 2テーブル目 ｽﾚﾘﾝｸ(db板)
PostgreSQL ＆ pgsql-jp ML 3テーブル目 ｽﾚﾘﾝｸ(db板)
5:NAME IS NULL
07/12/04 02:34:18
「ネタがない」と書いて思い出したんだけど、8.3の正式リリースはいつかな?
年明けにでもPCを入れ替えるものがあるので、どうせなら8.3をつっこんでやろうかと思ったり。
6:NAME IS NULL
07/12/04 09:38:05
>>5
今月とか来月じゃなかったっけ？
セミナーでベータ版使ってくれって言ってた。
7:NAME IS NULL
07/12/05 00:41:02 gLh1+dWI
1月だね
本家のMLに流れてた
8:5
07/12/05 00:53:45
>>6-7
サンクス。
初夏の頃にフリーズされてから結構かかったような。
こんなもんでしたっけ? 当初夏から秋にかけてリリースする
雰囲気だったような気もするのだが。
-- 素直に8.2を入れて頃合いを見て8.3へ上げることにすっかな。
9:NAME IS NULL
07/12/05 10:55:20
1月リリース予定のミニプロジェクトの開発で8.3beta使ってる。
初めて使うもので (MySQL からの移行)、せっかくだから Auto VACUUM あったら楽そうでいいかなとか。
Beta 4 の文字列が公式サイトで見られるけど、配布されているもののファイル名は beta3 だね…。
10:NAME IS NULL
07/12/05 11:05:25
AUTO VACUUMは8.1からあるべ
11:NAME IS NULL
07/12/06 09:01:33 symOClnh
beta4やっとで配布サイトに入ったな
12:NAME IS NULL
07/12/07 15:31:14 rx0IPmKF
CentOS5でphpPgAdminをrpmでインストールしようとしています。
URLﾘﾝｸ(phppgadmin.sourceforge.net)
↑のページの中断にRHEL用のrpmの置き場として、
↓へのリンクがあるのですが、NotFoundになっています。
URLﾘﾝｸ(ftp.icdevgroup.org)
どなたか他の置き場などご存知ないですか？？
13:NAME IS NULL
07/12/08 09:29:08
DB使用中の一覧は以下のSQLで見られるようですが、
select * from pg_stat_activity
その接続を強制切断（強制終了）はできるのでしょうか？
Windows版使用です。
14:NAME IS NULL
07/12/09 03:54:35 Pkpabdth
>>8
9.0とメジャーバージョンアップしてもいいぐらい
機能がてんこ盛りだからね。
レビューに時間がかかったみたい。
15:NAME IS NULL
07/12/09 04:05:49
ポスグレと怪獣フェドラはどんどん成長してしまって、
もうわかりませんわ。
16:NAME IS NULL
07/12/10 16:40:19
>>13
procpid でプロセスを終了させるといいようですが、
自分自身の接続のpostgres.exe の PID（procpid）を取得する方法はあるのでしょうか？
17:NAME IS NULL
07/12/12 08:49:31
>>16
つpg_cancel_backend()
18:NAME IS NULL
07/12/13 01:33:25 w5o1YGhv
>>17
16が知りたいのは自分自身のPIDを取得する方法
19:NAME IS NULL
07/12/13 12:04:20
>>18 のレスの意味がよくわからなかったので>>17のpg_cancel_backend調べたら
引数にpidいるのかｗ
\df でそれらしいの探したら pg_backend_pid() というやつで返ってきたけど。
20:NAME IS NULL
07/12/13 14:05:41
>>17-19
ありがとうございます。
select pg_backend_pid();
で自分自身の接続のpostgres.exe の PID（procpid）を取得できますね。
URLﾘﾝｸ(www.fiberbit.net)
select pg_cancel_backend(引数procpid);
で"t"（trueのこと?)が返ってくるけど、プロセスがKILLされるわけじゃないようだし。。。
pg_cancel_backend(引数procpid) の使い方がよくわからないけど、ま、いっか。（＾＾；
21:NAME IS NULL
07/12/13 14:11:46
pg_cancel_backend(引数procpid)
って、たぶん実行中だとキャンセルされるっていう意味なんだろーなー？！（想像）
22:NAME IS NULL
07/12/13 23:18:36 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
07/12/13 23:32:12
>>22
> 改行コードが\nのままの値
改行コードが含まれているんだから、表示すると改行されるのが当たり前。
「改行コードを『'\n'という文字列に変換』して」ということなら、
INSERT INTO Table VALUES(replace('123\n456\n789','\n','\\n'));
なんかでやればいいけど、それはもう改行コードじゃなく'\n'という文字列。
24:NAME IS NULL
07/12/13 23:33:24
>>22
URLﾘﾝｸ(www.postgresql.jp)
の4.1.2.1.
25:22
07/12/14 00:19:03 74gC5soq
>>23
>>24
どうもありがとうございます。
ちょっと試してみます。
26:NAME IS NULL
07/12/14 00:52:16
>>20
pg_cancel_backend()は実行中のSQLをキャンセルする関数。
プロセスを終了させるもんではないわな。
例えば、数分間結果が返ってこないSQLを一旦キャンセルしたいようなときに使う。
27:NAME IS NULL
07/12/14 02:15:50
>>26
やはりそうでしたか。
どうもです。
pg_kill_pid()なんていう関数があると便利なんですがねぇ。笑
28:NAME IS NULL
07/12/14 04:16:14
バカって悪用される可能性を考えないんだよな。
29:NAME IS NULL
07/12/14 05:05:24
プロセス切られることによって、それから悪用される可能性ってあるかなぁ？
30:NAME IS NULL
07/12/14 05:17:17
もっとバカはね、
postgres.exe 以外のプロセスもKILLできると勘違いしてるか、
プログラミングができない人だよ。
仮にKILLできても、su や admin なら問題ない。
31:NAME IS NULL
07/12/14 05:25:16
次の一手は、
『釣られてるよ』
ですかね？！
32:28
07/12/14 15:27:56
うえへへへへ、まったくバカだぜこいつ……orz
接続毎にバックエンドが上がるのを完全に忘れてた。
危険な機能には権限で対処てのは当然思ってたけど、
pg_cancel_backend(pid)も管理者権限がないと使えないんだな。
PQcancelと違って任意のバックエンドに対して使えるみたいだから
当然だけど。
13が意図してることはさっぱり理解も同意もできないし、
単に接続終了かキャンセル＋終了でよさそうなもんだけど、
調べてみるとpg_terminate_backend(pid)てのがソースにあった。
中身はSIGTERM送るだけ。
信頼性を損ねるからダメとコメントが付いてて使えないが。
長文スマソ
33:NAME IS NULL
07/12/14 17:05:37
プロセスの強制終了できないみたいね。
APIで強制終了できるのかな？
34:NAME IS NULL
07/12/14 17:17:27
>>32
＞単に接続終了かキャンセル＋終了でよさそうなもんだけど、
それってどういうコマンドですか？
その操作でプロセスも終了するんですか？
35:NAME IS NULL
07/12/14 17:23:54
32って反省文ですかね？
>>28
ちなみに悪用される危険性、わからないな。
悪用される危険性があるなら、されないように
関数を作ればいいんではないか？
36:NAME IS NULL
07/12/14 17:28:39
Linuxでは、該当のプロセス、KILLできますか？
37:NAME IS NULL
07/12/14 17:58:17
サービスの停止、最開始が手っ取り早そう。
なんの権限無しにできるのが、アレだけど。笑
悪用もへったくれもないが、さて、どんな風にからんでくるの？
38:NAME IS NULL
07/12/14 17:59:07
>>37
×最開始
○再開始
39:NAME IS NULL
07/12/14 18:03:27
>>37
Windowsの管理者権限だけが必要だね
40:NAME IS NULL
07/12/15 08:20:17
「今から HOGE.HOUR 時間前」 ってどう書けばいいですか?
CURRENT_TIMESTAMP - INTERVAL (HOGE.HOUR || ' hour')
と書いてみたが HOGE.HOUR で構文ネラーで撥ねられた。
41:NAME IS NULL
07/12/15 10:02:09
CURRENT_TIMESTAMP - CAST(HOGE.HOUR || ' hour' AS INTERVAL)
CURRENT_TIMESTAMP - (HOGE.HOUR || ' hour')::INTERVAL
42:NAME IS NULL
07/12/15 10:10:07
おお、でけた。
INTERVAL って前置演算子みたいなものかと思ってましたが、よく考えたら型でしたね。
ありがとうございました。
43:NAME IS NULL
07/12/15 16:02:06
PostgreSQL の INHERIT (テーブル定義) って中では内部結合でやってるんですか?
44:NAME IS NULL
07/12/15 21:07:52
Vistaに8.2.5が入らないと思ってたら、以下のページを見つけたのですが、
8.3ではインストーラの方でVista対応してくれるんでしょか？
URLﾘﾝｸ(www.iwahrt.com)
45:NAME IS NULL
07/12/17 08:59:44 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
07/12/17 14:00:41
自分は詳しくないので、答えられませんが、
詳細環境も提示したほうが答えやすいかも。
少なくともPostgreSQLのバージョンは。
47:NAME IS NULL
07/12/17 14:47:10
DB触り始めで大量データ扱うと、最初にぶつかるよなこれ。
SELECT文で条件指定しないで全取得すれば、データ全取得しようとするから
遅いし、（クライアントの）メモリが足りなくなるよね。
とりあえずは、条件設定したり、LIMIT OFFSET で件数絞ってやってごらん。
48:NAME IS NULL
07/12/17 14:50:17
条件設定して件数が少なくても遅いなら、プライマリキーやインデックスがどうなってるかもチェック
49:NAME IS NULL
07/12/17 16:18:17
>>47
サーバではなくクライアント側のメモリが足らなくなるというのがポイントですな。
クライアント側では、普通、何万件オーダーのSQLの返りを受け取れるようにはできていないので。
50:NAME IS NULL
07/12/17 16:19:54
カーソルの使い方覚えて、例えば10万件ずつFETCHするような
クライアントプログラムを書けばいい。
URLﾘﾝｸ(www.postgresql.jp)
URLﾘﾝｸ(jdbc.postgresql.org)
あとは、年月毎や銘柄毎でテーブルのパーティショニングを行うとかかね。
常にデータ全体をスキャンする必要があるならあまり意味無いけど。
URLﾘﾝｸ(www.postgresql.jp)
51:NAME IS NULL
07/12/17 17:00:25
まずはcout(*)でチェクしてから、
Limit とかoffset で抽出してみるのわ？
52:NAME IS NULL
07/12/17 17:03:15
count(*) ですね。
これもインデックス無いとかなり時間かかると思う。
53:NAME IS NULL
07/12/17 17:11:04
COUNT() ってインデックス関係あるんだっけ?
54:NAME IS NULL
07/12/17 17:54:48
WHERE句入ってれば場合によっては
55:50
07/12/17 18:00:28
8.3では同期スキャンの副作用でSELECTの度に結果が変動するリスクがあるため、
ORDER BY を付けずに LIMIT, OFFSET を付けたSELECT文の実行を繰り返すと妙な事になるかもしれない。
URLﾘﾝｸ(journal.mycom.co.jp)
全体のデータを取り出したいのであれば、
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
07/12/17 18:15:11
大昔に DB2 調べてて、ORDER BY + FETCH FIRST n ROWS ONLY 使うと
n 件の行を取ってきた後にソートするという動きで金玉もげるかと思ったのを思い出した。
57:NAME IS NULL
07/12/17 22:05:56 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
07/12/17 22:11:07
>>57
ノートPCでメモリ2Gでクライアント&サーバをやって
> それにしても、データだけでディスクをかなり占領するし、メモリ確保関係の
> エラーにも何回も遭遇するし、大量データを扱うのは大変ですね。
ってそりゃあ、おいおいって感じだ。
59:NAME IS NULL
07/12/17 22:16:00
零細がダイレクトメール用の情報扱ってるみたいな状況だな。
60:NAME IS NULL
07/12/17 23:17:42
7300万件w
61:NAME IS NULL
07/12/18 09:32:43
慣れればどうってことないけど、最初は少ない数でいろいろやったほうが
操作も覚えるしいいと思うがな
62:NAME IS NULL
07/12/18 14:06:28
>>57
データベースシステムを図書館と司書さんに例えると、
----------------例え話----------------------------
お客(クライアント)は、司書さんに「○○の本を貸してください(SELECT * FROM xxx WHERE ○○)」と問合せをかける。
お客は問合せの結果をバッグに入れてユーザーの所まで持ってくるわけだ。
藻前さんが最初にやったのは、図書館の本全部を一気にバッグに入れて持ってこさせようとした。そりゃ無理だ罠。
だからこそ、「○○な本のうち、50音順で500冊目から100冊持ってきて」という様に要求を区切って出したり、
「○○な本全体で、△△という単語が何回出現するか数えてきて」と集計する要求を出したりするわけだ。
DBのテーブルを分類ごとの書架だとすると、
その書架でも本がすごく多いモノ(例えば小説とか)を一定単位(作者別とか)で仕切るのをパーティショニングという。
パーティショニングされていないと、司書さんは書架全体の中から探す事になり、時間が掛かる。
インデックスっていうのは、図書館の蔵書を管理するカードの様なもので、それを元に検索すると素早く検索できる。
いくら司書さんが、本の扱いに慣れていても、一瞬一瞬に扱う本は1冊づつで、
その時扱っている本(インデックス含む)を差す指がカーソルという事だ。
----------------例え話----------------------------
株価のデータベースで、過去も含めた全てのデータを集計もせずに取り出す場面が(バックアップ目的以外で)あるとも思えない。
バックアップ用途なら、ダンプを取れば良いし、集計クエリやら条件付けやらをして、取り出す件数を絞れば、
メモリ不足でクライアントが動かなくなる事態がそうそう頻発するとは思えない。
OlacleやらMySQLにデータを移すなら、共通に使えるクライアント(ODBC等)経由で、
PostgreSQLのテーブルからSELECT INTOとか使って一気に流し込んじゃう方が楽だ。
63:NAME IS NULL
07/12/18 23:20:02 /fynqWlS
これかなーり便利だわ
URLﾘﾝｸ(pgfoundry.org)
64:age
07/12/18 23:53:42
よくわからないけど、自分には関係なさそう
65:NAME IS NULL
07/12/19 00:45:26 kklpHsFG
>>63
パフォーマンスチューニングするのに使えそうね。
そういえば8.3の全文検索機能試してる人いる？
66:NAME IS NULL
07/12/19 00:50:25
Ludia は試して… みたい
67:NAME IS NULL
07/12/19 10:38:38
>>62
57じゃないが、勉強になったThx
68:NAME IS NULL
07/12/21 03:10:15 fwC7Qy9u
JPUGの忘年会は盛り上がったの？
69:NAME IS NULL
07/12/21 10:46:56
あー、昨日だっけ。
参加できたなー、申しこむんだった
70:NAME IS NULL
07/12/27 00:25:14
v8.3はまだRCも出てないんだね
71:NAME IS NULL
07/12/27 08:24:23 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
07/12/27 10:49:45
スクリプト書いて両方にアクセスするって話でしょ？
psqlでDOBC使わないし。
ODBC使うツールでやってくれるやつもありそうだけど。
まあ実行可能ならdumpしたSQL食わせるのでいいと思うよ
73:NAME IS NULL
07/12/28 07:27:58
>>71
> # pg_dump -d kabu > dump_file
> # dump_fileを編集(テーブル一個の単純なDBなので、これは簡単そう)
本当に編集が簡単と思っているのか？
7000万件INSERTした結果のdump_fileなんだぞ？
なんか最初から見てるけど、感覚がおかしい。
74:NAME IS NULL
07/12/28 12:36:23 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
07/12/28 12:42:12
>>74
少なくとも
> それともDBの使い方がまずいのでしょうか？
なんてことを書いているようなレベルの人には
> これはやはり、多すぎると考えるべきなのでしょうか？
多過ぎるかと。
76:NAME IS NULL
07/12/28 12:48:55
>>74
抽出条件に対して適切にINDEX張ってれば
そんなに多いって訳でもないと思うが…
>>75の言うことももっともだと思う。
77:NAME IS NULL
07/12/28 14:39:10
少ないデータで仕組みきっちり作ってから
大量データ流し込んでチューニング
78:NAME IS NULL
07/12/28 21:26:08
>>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
07/12/29 08:56:26
仕事自体お断りする権限がないときは辞めるしかないか・・・
80:NAME IS NULL
07/12/29 10:08:24
>>79
作るだけ作って辞めるのもアリだなwww
ﾄﾞｷｭﾒﾝﾄ? ﾒﾝﾃﾅﾝｽ? ｼﾗﾈwww
81:NAME IS NULL
07/12/29 20:30:37
>>79
お断り出来ないときは、見積でふっかけましょう。
メンドクサイ客で予算が少ない時は、見積次第で客をコントロールする事は可能です。
自社の営業がヘッポコな時はむずかしいですが、
自社の営業を接待漬けにするぐらいの勢いがあれば危機対応能力は向上すると思います。
82:NAME IS NULL
07/12/30 22:50:01
見積もりで吹っかける→「いやーそれは高いでしょう」→見積もり減
見積もりするけんｇ（ry
83:NAME IS NULL
07/12/31 02:37:49
そうですか この見積もりでだめだとしますと他をあたっていただく事になりますが。
84:NAME IS NULL
07/12/31 13:18:59
つ～か、最初から予算ありきで
「お前らの見積なんぞ知らんがな。とにかくこれだけの金で作れ。」
・・・ってところも多いがな。
85:NAME IS NULL
07/12/31 17:03:38 n233Vr/g
8.3日本語版はいつでんの？
86:NAME IS NULL
08/01/02 10:20:25
日本語版って何よ
87:NAME IS NULL
08/01/02 14:47:49
すごいくだらないことかもしれなけど質問させてください。
ユーザーを管理するテーブルって何て名前にしてます？
user
はすでにあるみたいで使えないし
"user"
にすると、セレクトかける時も"user"にしなきゃならないし
tbl_user
とか接頭語や接尾語つけるのはあんまり好きじゃないし・・・
users
っていうのも考えたけど、なんでユーザーだけ複数なんだ？って感じだし
どうして、こんな一般的にみんな使いそうな名前を初期で入れてるだよ～
他の名前にしてくれればいいのに
まあ、どうでもいいから好きなのつけろって言われそうだけど、皆さんどうしてます？
88:NAME IS NULL
08/01/02 15:02:56
affiliate, associate, brother, comrade, constituent, fellow, joiner, member, sister
どうでもいいから好きなのつけろ
89:NAME IS NULL
08/01/02 17:13:26
>>86
URLﾘﾝｸ(www.postgresql.jp)
90:NAME IS NULL
08/01/03 01:08:09
>>89
本体は日本語版も何も無いだろう
91:NAME IS NULL
08/01/03 16:09:34
>>87
passwd
92:NAME IS NULL
08/01/03 17:34:40
>>90
そもそも本体の話しはしてない禿
93:NAME IS NULL
08/01/05 11:36:26
>>87
usertbl
94:NAME IS NULL
08/01/05 12:38:26
Oracleと性能比較した資料てどこかにある？
95:NAME IS NULL
08/01/05 12:58:23
>>94
そんな資料は出せないはず。Oracleが禁止してなかったっけ？
昔の話だから、今はどうか知らないけど。
96:NAME IS NULL
08/01/05 20:22:55
データ型として配列を使っています。
配列の要素にNULLが存在する場合にマッチするクエリは、どのように記述するのか教えてください。
PostgreSQL 8.3beta4です。
97:NAME IS NULL
08/01/05 20:45:32 Ible2iRH
URLﾘﾝｸ(click.j-a-net.jp)
98:NAME IS NULL
08/01/06 12:11:23
>> 96
自前で比較用の関数用意するしかないんじゃね。
ANYとIS NULLの組み合わせじゃダメだし。
99:NAME IS NULL
08/01/06 20:18:51
>>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
08/01/07 12:56:11
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
このページのConstraint Exclusionは、条件に合う部分だけ検索がかけれるということなのでしょうか？
実際に試してみたところ、テーブル内を全て検索するのと速度があまりかわらないような気がするのですが・・・
PostgreSQL 8.2.5です
101:NAME IS NULL
08/01/07 23:12:54
2008-01-07 Cumulative Security Update Release (8.2.6, 8.1.11, 8.0.15, 7.4.19 and 7.3.21)
URLﾘﾝｸ(www.postgresql.org)
PostgreSQL 8.3RC1 is out.
URLﾘﾝｸ(www.postgresql.org)
URLﾘﾝｸ(www.postgresql.org)
102:NAME IS NULL
08/01/07 23:19:12
っと、まだ8.3rc1はアナウンスされておらず勇み足だったらしい。すまぬ。
103:NAME IS NULL
08/01/08 08:03:14 NK7MHFFt
今朝見たらアナウンスされてました。
しかし8.3は難産ですね。RCも1で終わってくれるのかな･･･？
104:NAME IS NULL
08/01/08 08:52:18
URLﾘﾝｸ(www.postgresql.org)
URLﾘﾝｸ(archives.postgresql.org)
8.3rc1のアナウンスはまだじゃない？と見てたら、pgAdminIII 1.8.1 が出てるね。
pgAdmin III v1.8.1 released
URLﾘﾝｸ(archives.postgresql.org)
105:NAME IS NULL
08/01/08 12:50:49
PostgreSQLに危険なセキュリティ・ホール，管理者はバージョンアップを
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
106:NAME IS NULL
08/01/08 23:54:49
PostgreSQLに脆弱性：バージョン7.3ブランチのサポート打ち切りに
URLﾘﾝｸ(builder.japan.zdnet.com)
PostgreSQL 7.3ブランチが終了：8.2系へアップグレードを
URLﾘﾝｸ(builder.japan.zdnet.com)
後者の記事は、Windows版バイナリとそれ以外のEOLの話をごっちゃにしているのが何とも。
107:NAME IS NULL
08/01/09 03:56:47
Windows版 8.3 に期待してるのだけど
通常、PC-Unix 版に比べてどのくらい遅れてリリースされるのかな。
108:NAME IS NULL
08/01/09 20:39:00
>>107
普通は遅れはほぼゼロ。
109:NAME IS NULL
08/01/10 00:13:06
sequenceをデフォルトテーブルスペース以外に作成する方法はないんかいな？
マニュアル見ても、create/alter でテーブルスペース指定することはできないし、
serial型で自動作成されるsequenceも指定できないし。（テーブルが別テーブルスペースでもsequenceはデフォルト域になってしまう。）
最新の8.3でもだめそう。
だれかこの件について情報持ってないですか？
ちなみに、pg_classのテーブルスペース情報をupdateして、物理ファイルをmvしたら、なんとなく動いてるいるようには見える。が、さすがに本番では怖いのでやってない。
110:NAME IS NULL
08/01/10 02:13:10
>>108
サンクス
111:NAME IS NULL
08/01/10 02:13:20
>>109
そもそもSEQUENCEを別のテーブルスペースに作成する意味はあるの？
メリットが分からん。
あと、pg_classをUPDATEしなくても、移動した物理ファイルに対して、
ln でリンクを作ってやればいいんじゃない？
112:NAME IS NULL
08/01/10 07:28:05
>> 109
設定パラメータ default_tablespace を変更してもダメ？
>> 111
> SEQUENCEを別のテーブルスペースに作成する意味はあるの？
誰しもそう思っているから、むしろ忘れられていたのかも。
機能としてはあってもかまわない気はする。
113:NAME IS NULL
08/01/10 21:50:07
java+tomcatであるテーブルの列を５０づつ表示するロジックを作ったとします。
まずはじめの0～50は正常に表示されるのですが次の50を表示するを選択すると
50～100までの表示ではなく50～ラストまでの表示になってしますのです。
SQL文は次のようになっています"select * from -- where number > "+number+" and number <= "+number+50;
何か間違っていることがあれば指摘してください。お願いします。numberの変数はデバッグで意図した値な事を
確認しています。なおnumberはserialです。
114:NAME IS NULL
08/01/10 21:53:18
>>113
知らんがな。実際に発行されているSQL文を0～50と50～100の時で
どうなってるか確認して、psqlで実行してみなよ。
115:NAME IS NULL
08/01/10 22:22:12
LIMIT OFFSET のが簡単な気も
116:NAME IS NULL
08/01/10 23:01:47
>>113
全然関係ないけど、実験の時でも普段から PreparedStatement 使うようにしとくといいぜ。
117:NAME IS NULL
08/01/11 00:05:06
>>113
String + int + int って、((String + int) + int) って解釈されね？
n = 0 なら "number <= 050" で上限は 50 と解釈されるけど、
n = 50 だと "number <= 5050" になる気がするんだが。
「number <= " + (number+50)」と括弧を付ければ良いのでは。
118:NAME IS NULL
08/01/11 00:14:40
同じ演算子の優先順位は左から右だから >>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
08/01/11 00:51:40
>>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
08/01/11 09:06:04
詳しい説明ありがとうございます。
121:113
08/01/11 09:08:10
が、numberはintです。
122:NAME IS NULL
08/01/11 09:11:29
>>121
だからさぁ、PostgreSQL的にはそんなことどーでも良いんだよ。
サーバ側で処理したSQLをチェックしろ。
意図した通りのSQLになっていて、取得結果がおかしいなら
ここで質問するのはありだが、プログラムの間違い探しなら
よそでやれ。
123:113
08/01/11 09:29:57
失礼しました。>117様の言う通りでした。
124:NAME IS NULL
08/01/11 11:14:28
"select * from -- where number > " や " and number <= " は文字列だからな。
しかしどれ使うにしても、ORDER BY つけないとな。
そして、実行するSQL文を吐き出してpsql等で確認するのは常に必須。
125:NAME IS NULL
08/01/11 15:38:10
あらかじめ用意されたテーブル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
08/01/11 20:54:51
>124 なるほど～order by という便利なソート機能があったんですね。
更新すると列が最後尾にくるので"どうしたもんか？"と思っていたところでした。
情報ありがとうございます。
127:NAME IS NULL
08/01/11 21:42:42
>>119
> つまり、SEQUENCEのNextValを取得する際のI/O分散です。
それはさすがに意味ないと思う。千～万単位で SEQUENCE 作るつもりでない限りは。
たいていはキャッシュに乗ってる。
バックアップなり信頼性目的ならば、ありうる状況かも。
128:NAME IS NULL
08/01/11 23:34:41
>>127
今回の疑問は、そもそも、sequenceのテーブルスペース変更はできないのは何故なのか？
という好奇心的なものが発端でして、実質的に問題が発生しているわけではありませんけどね。
対応してないなら仕方ないですね。少し残念です。
129:NAME IS NULL
08/01/12 01:08:46
>>125
それは、どう変わることが期待されてんの？
130:NAME IS NULL
08/01/12 11:39:49
>> 125
timeを検索条件にした？
131:NAME IS NULL
08/01/12 12:31:21 bIgQT3Xd
>>125
Ａというテーブルが親なら、 Ａ1 Ａ２ Ａ３ Ａ４という子の
テーブルを継承で作成する。そんで、Ａ１ Ａ２といった子に
insert する。そうすると親のＡに対してselect すると、子を見て
くれて、制約があれば関係ないのは除外するという仕組み。
132:NAME IS NULL
08/01/14 19:14:38
質問です。
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
08/01/15 01:04:38
>>132
> (リネーム時に何かしらデータ量に応じた処理が行われますか？)
行われない。
たぶんシステムカタログの一部が更新されるだけ。
> アクセスのタイミングによっては、ユーザーには、空データが表示されてしまうのでしょうか？
一瞬だけど TABLE_A が存在しないタイミングがあるから、
そのときのアクセスはエラーになる。
134:NAME IS NULL
08/01/15 01:25:31
エラーじゃなくてテーブルロックの解除待ちじゃないかな。
他からTABLE_AとTABLE_Bを順次SELECTされた場合、
タイミングによっては片方のテーブルを2度読みしちゃう可能性があるけど。
135:133
08/01/15 02:02:36
>>134
ALTER 文が BEGIN, COMMIT で囲まれてるの見のがしてた。
ロック待ちだね。
> 他からTABLE_AとTABLE_Bを順次SELECTされた場合、
> タイミングによっては片方のテーブルを2度読みしちゃう可能性があるけど。
1トランザクションで ALTER 文を全部実行してるから、2度読みはないはず。
136:134
08/01/15 02:45:10
>>135
> 1トランザクションで ALTER 文を全部実行してるから、2度読みはないはず。
TABLE_Aを読み出して、TABLE_Bも読み出そうとしたら >>132が走ってロック待ち、
解除後TABLE_Bを読み込んだら、それはリネームされる前のTABLE_A。
137:NAME IS NULL
08/01/15 07:53:27
>>136
最初に全部ロックを取ってしまうのはどうだろう。
BEGIN;
LOCK TABLE_A IN ACCESS EXCLUSIVE MODE;
LOCK TABLE_B IN ACCESS EXCLUSIVE MODE;
...
138:NAME IS NULL
08/01/15 08:06:32
ていうかそういうのは読み込み側がトランザクション分離レベルやテーブルロックを適切に設定してないだけじゃん。
139:NAME IS NULL
08/01/15 12:57:46 L9najbhe
※nextval(text)とcurrval(text)について
PHPからDBにアクセスしIDを表示するようなシステムを作っています
CREATE TABLE test_tbl (id SERIAL PRIMARY KEY,memo TEXT);
というテーブルがあり
idカラムの番号を表示で利用する場合
１）が正しい気がしますが２）でも大丈夫なきもします
１）と２）どちらがpostgres(DB)としては安全で正しい運用方法
なのか教えていただけないでしょうか？
１）IDを前もって取得し変数($id)に入れて使いまわす方法
SELECT NEXTVAL('test_tbl_id_seq');
BEGIN
INSERT INTO test_tbl(id,memo)VALUES($id,'AAAA');
COMMIT
２）IDを後から取得して使う方法
BEGIN
INSERT INTO test_tbl(memo)VALUES('AAAA');
COMMIT
SELECT CURRVAL('test_tbl_id_seq');
140:NAME IS NULL
08/01/15 22:40:11
>>135
ふつう、DDLにトランザクションは効かないか発行時点でcommitされてしまうと思うが。
と思って調べてみたら、SQLServerはDDLもrollbackできるんだな。
141:NAME IS NULL
08/01/15 22:43:09
DB2 でも普通にできるが。
142:NAME IS NULL
08/01/16 00:22:19
>>136
両テーブルのSELECTも、トランザクションで実行するもんだと思うが。
143:NAME IS NULL
08/01/16 00:55:16
>>139
どっちでも完全に一緒。お好みで。
PostgreSQLの方言でよければ RETURNING もアリ。
INSERT INTO test_tbl(memo) VALUES('AAA') RETURNING id;
144:NAME IS NULL
08/01/16 01:13:31 13aLpW9J
>>133-138
>>140-142
ご回答ありがとうございます！
大変参考になりました！
ただ、考えてみれば、
テーブルデータ更新中のアクセスに対応するための方法だったので、
更新失敗によるデータ破損や、自前の例外処理を心配するぐらいなら、
最初から1テーブルで、データ更新 (COPYで行う) 自体をトランザクションで行う方が安全だと気づきました…。
で、シーケンスを更新する、と。
ただ、空データ表示時間があったとして、その機会損失損害額を考えると
どういう方法がベストなのか今でも分かりませんが…。
ああ、SEへの道は遠いなぁ…。
皆さん、どうもありがとうございました！
145:NAME IS NULL
08/01/17 04:44:40 EaOIQdVo
Sun、MySQLを買収へ
URLﾘﾝｸ(www.itmedia.co.jp)
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
08/01/17 10:49:44
8.3で忌まわしきVACUUMが無くなるって話を聞いたんだが、これって公式にアナウンスされてる？
もしVACUUMが無くなるならば、ようやく使えるDBになるな
速度の問題だけじゃなくて、VACUUMの手間を避けたいがゆえにMySQLに行った人って多いでしょ
147:NAME IS NULL
08/01/17 10:53:35
> 今回Sunが買収したことで、OracleやMicrosoft、
> IBMなどとデータベース市場で争うための基盤をSunは手に入れたことになる。
( ´д)ﾋｿ(´д｀)ﾋｿ(д｀ )
148:NAME IS NULL
08/01/17 12:27:46
バキュムはどっかでやってるだけでしょ。
てか普通に空いた時間でやってくれてると思うが、
そんなに面倒かな。
149:NAME IS NULL
08/01/17 16:25:33
>>148
My SQL使いは Auto VACUUM の存在を知らない人が多いよ
というか、もはやPostgreSQLに目もくれないご様子で…
150:NAME IS NULL
08/01/17 18:08:10
なんでMySQLの話題ばかりなんだよ。
というわけで
SRA OSS、PostgreSQL 8.2をベースにしたHAクラスタソリューション
URLﾘﾝｸ(enterprise.watch.impress.co.jp)
なんて話題を振ってみる。
HAクラスタソフトにはLifeKeeperを使っているとのこと。
151:NAME IS NULL
08/01/17 18:41:57
>> 150
> ベースとなるPostgreSQLが8.2.5へバージョンアップ。
最近のセキュリティフィックス入ってないじゃん。
152:NAME IS NULL
08/01/17 21:56:40
まぁデフォルトで autovacuum が on になるから、
「設定不要になった」と言っても嘘にはならないだろう。
「VACUUMが無くなる」という発想そのものは、何も分かっていない証拠。
Oracle で UNDO セグメントを無くせないとのいっしょ。
153:NAME IS NULL
08/01/17 22:14:51
どうでもいいから日本postgresqlユーザ会、8.3の日本語版早く出してくれ。
154:jin
08/01/18 11:18:11 EMckNTsF
Postgre for windowsのチューニングについて教えてください。
64bit版の機器で16GBのメモリをつんだ機器でポスグレをインストール
したのですが、Shared Memoryを1GB以上にするとポスグレが起動できません。
16GBつんでるのでメモリを最大限まで使用したいです。どうしたらいいので
しょうか。教えてください。
155:NAME IS NULL
08/01/18 15:22:21
>>154
バージョンいくつ？バイナリは32ビット版だよね？
156:154
08/01/18 16:10:40
サーバー用にOS:VISTA PC買ったらPOSTGRESQLインスト出来ねえでやんの；
その時オワタおもた。
157:NAME IS NULL
08/01/18 16:12:26
失礼。ミスた俺は>154じゃない。
158:NAME IS NULL
08/01/18 23:01:42
Windows 用の 64bit バイナリってあったっけ？
少なくとも配布されているのは 32bit 版だけだったような…。
必ずしも shared_buffers にメモリを全部割り当てる必要は無いから
(OSがキャッシュに使ってくれる) 1GB で我慢しれ。
159:NAME IS NULL
08/01/20 00:59:56
URLﾘﾝｸ(japan.cnet.com)
> 最近利用が増えてきているPostgreSQLと比較しても、約2倍ほど
> 高速に動作します。
デマが流れてるぞ
160:NAME IS NULL
08/01/20 01:42:32 rsAddFWz
>>159
だれだ さぁや って知ったかライター（インチキ）か。
posgreSQLにもMySQLにも迷惑だ。潰してやれ。
161:NAME IS NULL
08/01/20 13:27:12
>>160
迷惑だと言えば、MySQLスレに出張して、
やたらとSunの買収について不安を煽っている人間がいたね。
大人げ無いから止めとくれ。>>152=>>158
162:NAME IS NULL
08/01/20 14:33:36
ゼイタクギガサーバーがあまりにも贅沢すぎるw
163:NAME IS NULL
08/01/20 17:00:55
postgreSQLはMYSQLと比べて便利すぎる。
164:NAME IS NULL
08/01/20 22:18:45
MySQLは商用版も出てたし、業界再編の波に飲まれているのでは？
165:NAME IS NULL
08/01/20 22:51:34
安定して使えりゃどっちでも良いよ
166:jin
08/01/21 09:20:39 Q97Sm1d1
ver.はPostgreSQL 8.2.6です。確かに32bit版のようです。出来る限り16ＧＢ
のメモリを効率的に使用して処理速度をあげたいです。shared_buffers以外
にもどの部分のチューニングをすればいいのでしょうか。教えてください。
167:NAME IS NULL
08/01/21 11:27:09
アナウンスがまだだけど、PostgreSQL 8.3 RC2。
URLﾘﾝｸ(packages.debian.org)
168:初心者
08/01/21 15:28:41
初心者です。
PostgreSQL のユーザ定義関数を使って和暦変換関数を作成したいのですが
IBMのICU4Cを使ってC++で和暦変換関数を作成しました
C++で作った和暦変換関数を組み込もうとしてるのですが、
C関数でないせいかうまくいきません。
誰か詳しい方教えてください。
169:NAME IS NULL
08/01/21 16:48:37
C++で作ったって、外部向け関数だけをCリンケージでやったらいいんじゃないかな。
170:NAME IS NULL
08/01/21 16:49:42
>>156
Vistaへのインストールはコツがいる。
ググってわからなかったらまたおいで。
171:NAME IS NULL
08/01/21 18:42:22
>>168
まず、どのように「うまくいかない」のか書くべし。
postgres のヘッダで、typename や delete なんかの C++ のキーワードを
仮引数名として使っている箇所があったような気がする。
postgres と繋ぐ箇所だけを別のCソースで書くか、
include 前に #define typename typename_ で誤魔化すか。
172:初心者
08/01/21 20:49:30
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
08/01/21 20:57:30
>>172
extern "C"とかで解決する問題？
174:NAME IS NULL
08/01/21 21:40:42
ヘッダファイルで
#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
08/01/21 22:44:12 17f4QTHj
ハードディスクがあふれないようにテーブルの行数に制限つけろと言われた。
100年以上運用しても余裕があるっていう資料出したのに仕様に入れてきやがった…
cronで定期的にcount取って制限に達したら古いデータを削除しようと思うんだが、
これぐらいしか方法無いよねぇ？
176:NAME IS NULL
08/01/21 22:46:04
>>175
トリガ使って都度チェックとか
177:NAME IS NULL
08/01/21 22:47:59
>>176
insertのたびにcountって重くね？
178:NAME IS NULL
08/01/21 22:51:51
>>177
どれくらいの行数を想定しているとか分からないから、知らんがな。
そんなこと言われても、方法を提示しただけです。
179:NAME IS NULL
08/01/22 00:54:34
>>175
行数より実際のディスク容量を監視した方がよくないか？
デッドタプルみたいに、行数には現れないが容量喰うものはあるわけで。
180:NAME IS NULL
08/01/22 10:10:05 tyWoTrKG
>>167
PostgreSQLの公式ページで正式にRC2が発表された模様
181:NAME IS NULL
08/01/22 15:46:20
そういえば、8.3ってそもそもは昨年中にリリースするつもりじゃなかったっけ?
182:NAME IS NULL
08/01/22 17:43:02 7/qXfoyh
00000_1
00000_2
11111_1
といったデータがあった場合、
group byを使って00000をまとめることはできないものでしょうか。
もしありましたらご教示いただけますと幸いです。
183:NAME IS NULL
08/01/22 18:27:56
GROUP BY SUBSTR(str, 0, 6) とか？
184:NAME IS NULL
08/01/22 22:42:35
>>179
仕様で行数って書いてあるんだから気にしない
185:NAME IS NULL
08/01/22 23:05:16
>>172
char *t に対して VARSIZE(t) しているのが間違い。
DirectFunctionCall1(textin) でもしておけ。
186:NAME IS NULL
08/01/23 14:04:34
>>175
ちょっとトリッキーな方法かもしれんけど…
・serial型の列を作成して、それを主キーにする。
・自動的に作成されるシーケンスにMAX値とCYCLEを指定する。(MAX値は最大行数)
・主キーが重複したら削除するBEFORE INSERTのトリガーを作成する。
・取り出すときはINSERT時間でも入れといて、ソートする。
187:初心者
08/01/23 23:52:29
>>185
何度もすみません。
どんな感じでDirectFunctionCall1(textin)を使えばいいのですか？
DirectFunctionCall1(textin,CStringGetDatum(t));
みたいな使い方でいいんですか？
教えてください。
188:NAME IS NULL
08/01/24 08:04:47
>>187
「DirectFunctionCall1(textin」でウェブを検索なり、Postgresのソースコードをgrepなりしてみなさい。
もし前例があれば、正しい使い方だと判断すればいい。
自分で考えるのを放棄して教えを請うのは「初心者」だからといって許されない。
189:NAME IS NULL
08/01/24 11:20:06
自分で調べたり考えたりググったりしない人間は、
DBやらプログラミングやらには激しく向いてない気がしてならない今日この頃
190:NAME IS NULL
08/01/24 14:02:21
何にも向いていない。
てかあるレベルで止まる。
191:NAME IS NULL
08/01/24 17:17:30
pg_dumpしようとすると
pg_dump: query to get table columns failed: ERROR: kind mismatch between backends
といったエラーが発生するのですが、pg_dumpを使わずにとりあえず
バックアップできる方法があればご教示願います。
権限は一つのDBに対して与えられているだけで、postgres権限はありません。
192:NAME IS NULL
08/01/24 17:29:35
>>191
pgpool使ってる？
193:NAME IS NULL
08/01/24 17:52:08
>>192
はい、使ってます。
色々調べてみましたところ、oid等が2台のサーバでずれている
可能性があるみたいですが、ユーザ権限では今のところどうし
ようもないという結論に至ってます。
せめて定期的にバックアップだけはとっておきたいと書き
込ませていただきました。
194:NAME IS NULL
08/01/25 07:15:51
pgpool経由じゃなくて、直接PostgreSQLにpg_dumpすればOK。
195:NAME IS NULL
08/01/25 15:47:09
>>194
アドバイス感謝です。
pgpool経由ではないようにpg_dumpすると言うことは、
各種DBサーバへ入って直接pg_dumpを行うという認識
で宜しいでしょうか。
/usr/bin/pg_dump -h 127.0.0.1 DB > backup.db
DBサーバへログインし、上記で試してみましたが、
やはりどちらからやっても同じエラーが出てしまい
ました。
大変恐れ入りますが、ご教示いただけますと幸いです。
196:NAME IS NULL
08/01/25 16:07:47
pgpoolへのポートじゃなくて、pgpoolが使ってるPostgreSQLへのポートを指定するのよ
197:NAME IS NULL
08/01/25 16:11:05
>>195
同じエラーって、それpgpoolに繋がってるんじゃ？
そのエラーメッセージはpgpoolが出してるんだけど。
違うポート番号で立ち上げてるんじゃないの？
198:NAME IS NULL
08/01/25 19:58:28
>>196-197
PostgreSQL指定ポートというものがわからなかったため、
とりあえず5433で以下実行しましたらいきましたので
取り急ぎご連絡させていただきます。
/usr/bin/pg_dump -h 接続IP DB -p 5433 > backup.db
本当に有難うございます。
また何かありましたら報告させていただきます。
199:NAME IS NULL
08/01/25 23:03:32
この辺は身体でわかってないと、無理だね。
一歩ずつね。
200:NAME IS NULL
08/01/27 00:48:13
便乗質問だけど、pg_poolってデフォルトでは5432
ポートで動いているんですか？
>>198は5433でPostgreSQLへ繋いでるみたいだけど。
201:NAME IS NULL
08/01/27 00:53:29
>>200
そりゃあ、クライアント側の設定はそのままでいけるように、pgpoolは5432でしょう。
202:NAME IS NULL
08/01/27 10:17:02
＋１するのはセキュリチやラッパでよくあるね。
おらくるでは１５２２とかw
203:NAME IS NULL
08/01/28 11:26:23 SakCgkQ0
initlocationってなくなっちゃったの？
204:NAME IS NULL
08/01/28 14:16:08 qNEN3OcM
横からすみません
私はpgpoolじゃなくslony1使ってるんですが、
8.1でpg_dumpしたデータを8.2にリストアするとプロセスが落ちてしまいます。
落ちるのは毎回決まった場所で、
リストア中に｢SET｣という表示が出るあたりで処理が固まってしまいます。
何か心あたりある方いないでしょうか。
205:NAME IS NULL
08/01/28 15:13:14
漢字使ってる？
206:204
08/01/28 15:19:51 qNEN3OcM
>>205
私ですか？
使ってます。
ちなみにpg_dumpのとき文字コードは何も指定してません
-Eつけずに実行しました
207:NAME IS NULL
08/01/28 16:07:48
んー、Slony-Iの無い8.2に入れて、そこからまたdumpするとか。
8.2は文字コード厳しいんだよねえ、8.1と比べると。
208:NAME IS NULL
08/02/03 01:46:04 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
08/02/03 08:57:15
>>208
UNIONだろｗ
UNIONじゃなくてもCASEで1,2を分けてもいいかな。
210:NAME IS NULL
08/02/03 11:39:03
SELECT *, CASE WHEN XXX THEN 0 ELSE 1 END AS flag FROM table1;
211:NAME IS NULL
08/02/04 09:32:31 htIE4kq7
PostgreSQL 8.3.0
212:NAME IS NULL
08/02/04 11:05:26 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
08/02/04 15:44:34
>>211
2008/02/01にダウンロードできるようになってるけど、
トップ更新もまだだしリリースノートもまだだねぇー。
最終チェック中？
214:NAME IS NULL
08/02/04 20:40:02 q5dGF2Ty
記念あげ
215:NAME IS NULL
08/02/04 23:18:37
URLﾘﾝｸ(www.postgresql.org)
216:NAME IS NULL
08/02/05 11:43:01
pgAdminⅢでリストアするときに
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
08/02/05 17:31:00
pgadminはバグが多いので、PostgreSQL本体の付属品ではなく、
単品の最新版をインストールすべき。それでもやっぱりある程度の
大きさのSQL流し込むとやっぱりダメなことが多いけど。
ってことで、大きなSQLを叩き込む場合は、素直にコマンドラインの
psqlを使ったほうがいい。
218:NAME IS NULL
08/02/05 20:14:12
8.3キターー
219:NAME IS NULL
08/02/05 20:36:09 z0f3Z9+p
すいません質問があるんですけど・・・
重複したデータを削除したいのですが記述の仕方がわかりません．．
条件が非常に縛られているので削除方法がわからないんです．．．
このようなデータベース
↓
○テーブル名：main1
・カラム：id, name
○テーブル名：main2
・カラム：id, info
○テーブル名：relation
・カラム：id, main1_id, main2_id, point
以上のような３つのデータベースを作りました．
relationはmain1とmain2の関連テーブルになっています．
ここで問題が起きたのですが，relationにはmain1とmain2のidを結びつけたインスタンスが
登録されています．
なのでmain1とmain2のidの組み合わせが重複することはないのですが，なぜか
存在してしまいました．
つまり，main1とmain2のidが等しいデータが違うidで存在しています．
この重複部分を削除したいのですがわからないのでカキコしました．
消すデータは後ろのidの方のデータを消したいと思っています．
このrelationのデータ数が非常に多いので，手動では時間がかかりすぎるのでSQLで解決したいんです！
どなたか教えてくれませんか？？
一度，重複しているidをすべて１度selectしてからdeleteしても全然おｋです．
220:NAME IS NULL
08/02/05 20:55:50
>>219
truncate main1;
truncate main2;
truncate relation;
でいいよ。重複部分もちゃんと削除される。
221:NAME IS NULL
08/02/05 21:03:53 gyamhWYh
TRUNCATE -- 1テーブルまたはテーブル群を空にする
ただでさえ人少ないのにさらに減らすようなことやめようよ。
222:NAME IS NULL
08/02/05 21:32:15
>>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
08/02/05 23:51:47
>>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
08/02/05 23:52:26
>>223
あ。最後に return 0; とか書いておいてね。
225:NAME IS NULL
08/02/06 07:54:42
>>223 むしろ遅くなるぞ。
>>222 がどういう実行プランに落ちるか、イメージできているのか？
relation へ SeqScan 1回で済むような方式でなければ、222を超えられない。
226:NAME IS NULL
08/02/06 09:03:43
>>225
indexがあるかどうかもわからないのに、どちらとも言えないでしょ。
227:NAME IS NULL
08/02/06 10:19:10
>219 8.2の初期バージョンはリストアしても完了にならないバグがあるから
何度もok選択するとデータがダブって入る。
228:NAME IS NULL
08/02/07 00:43:43 cSQE2+AL
今までAccessとSQL Serverしかさわったことがなく、
はじめてPostgreSQLを phpPgAdmin でさわっているんですが、
Accessでいうリレーションの設定は、外部キーの追加 にあたるのでしょうか？
また、リレーション図の作成といった機能、または外部ツールなど
ありましたら教えてください。
よろしくお願いします。
229:NAME IS NULL
08/02/07 00:56:30
リレーションはSQL文発行するときに毎回作成するんだよ
リレーション図作るならACCESSからODBCでテーブルリンクしてやっちゃった方が手っ取り早いと思う
230:228
08/02/07 01:04:32
さっそくのレスありがとうございます。
なるほど、そういう手がありましたか ＞ACCESSからODBCでテーブルリンク
リレーションについてですが、すみません、おそらく
自分が言いたかったのは、参照整合性のことだと思います。
それはやはり外部キーのことでしょうか？
231:NAME IS NULL
08/02/07 07:36:05
>>230
YES. 参照整合性 = 外部キー制約
URLﾘﾝｸ(www.techscore.com)
>>229
リレーションって単にテーブルの意味で使うような。
232:NAME IS NULL
08/02/07 12:10:58 Zq40oyH1
SQLサーバーとアクセスで、年商100億以下の企業のシステムが組めるそうです。まさに、オフコンキラー・エンドユーザーキラーです。
233:228
08/02/07 23:12:53
>>231
ありがとうございました！
ようやく分かってきました
234:NAME IS NULL
08/02/08 15:50:41 HqMhws4W
バージョン:8.3
costとactual timeを比較しながらSQLチューニング
を行っています。
そこで質問なのですが、「costが激減したがactual timeが早くならないという」
現象は普通起きるのでしょうか？
もし起きたとすれば、それはDBサーバの処理能力が低いことが
原因と考えても宜しいでしょうか？
宜しくお願いします。
235:NAME IS NULL
08/02/08 20:28:16
どのDBでもそうだけど、コストっていうのは
こうしてそうしてああすればこうなるっていうのを数字にしたようなものなので
それを改善すれば必ず速くなるというものではない。
CostっていうのはSQL文の中のボトルネックを探すのに使うとよいと思う。
236:NAME IS NULL
08/02/09 15:38:14 Mdw0byD5
助けてください。
8.2.3です。
Debian上で動作しているPostgreSQLサーバの管理をすることになりました。
このＤＢは社内システム用に使っています。
これまでほとんど管理されてなかったサーバなので、まず色々調査しなければなりません。
しかし前任者が先日、事故で死亡してしまい、情報がありません。
ログインアカウントは現在、メモなどを探しているところなので、まだサーバに入れていません。
私はこれまで、単なるPGをしていたのでDBの管理なんて何をしたら良いのか分かりません。
まずは何をしたら良いのでしょうか？
HDDの容量見たり、topで確認したりはするつもりです。
バックアップがどうなっているかも調べるつもりです。
それと、バキュームしないとまずいよね、と聞いたので、まずはそれをするつもりですが、
他にすることはありますか？
237:NAME IS NULL
08/02/09 15:50:23
止める時間と別マシンがあったら、鯖からHDDすっこぬいて別のマシンにつなぎ、別マシンのルート権限で
旧マシンの/etc/passwd の周り書き換えるなり移植するなり。
つーか全部ここで言うことじゃねえや。
238:236
08/02/09 16:03:22
>>237
アドバイスありがとうございます。
アカウントが見つからなければその方法で試してみます。
なるべく止めたくないので、もう少し頑張ります。
239:NAME IS NULL
08/02/09 18:49:46
>>236
アカウントやパスワードは、
使用しているアプリケーションのソースを見たら検討つくのでは？
ログインのソースとか。
あと日次や月次などバッチ処理などが深夜などに、
別途、稼動しているかどうかも確認したほうがいいでしょう。
バキュームやバックアップもバッチで自動で行っているかもしれないでしょうし。
240:234
08/02/10 00:32:05
>>235
ありがとうございます。
必ず速くなるものではないんですね…勉強になりました！
241:NAME IS NULL
08/02/10 09:35:21
ぱっと思いつくだけでも
rootになって全ユーザのcrontabチェックしてバックアップとバキュームしてないか確認。
ついでに、バッチでDBアクセスがないか確認。(時間も控えとく)
DBの設定みてオートバキュームしてないか確認。
リモートから接続許可してる場合、許可してるマシンからもバックアップ、バキュームしてないか確認。
資料探しまくって手動cronがないか確認。(○曜日に出社したらなにかするとか)
クライアントの利用時間帯やらをヒアリング。
わかったことは全部ドキュメントに残す。
242:236
08/02/10 14:04:58
>>239
あ、たしかにアプリケーションのソースを見れば分りますね。
会社に行ったら確かめてみます。
>>241
手動cronは私の発想からは出てきませんでした。
ありがとうございます！
243:NAME IS NULL
08/02/11 20:33:23
PHPやってて
GETで持ってきた引数をデコードした文字列を問い合わせ文のWHEREの条件に入れるとうまくいかないんですがどうしてでしょうか？
アドバイスよろしくお願いします
244:NAME IS NULL
08/02/11 20:47:25
相手に伝える言葉の使い方が分かっていないから
245:NAME IS NULL
08/02/11 22:26:20
SQL文を勉強しましょう
SQL文を検証しましょう
二行ですむな
246:NAME IS NULL
08/02/12 05:35:17
>>243
シングルクオートの処理が間違ってるんじゃないか？
247:NAME IS NULL
08/02/12 15:24:22
MLのインストールの話題だけど普通は自前コンパイルなのか？
CentoOSな俺は URLﾘﾝｸ(yum.pgsqlrpms.org) で入れてる
248:NAME IS NULL
08/02/14 01:27:38
Solarisだから普通にビルドしてるなあ
最近も64ビットでビルドするからなおさら
249:204
08/02/15 00:03:26
とりあえず報告を。
バージョンアップうまくいきました。
原因はSlony-Ⅰでした。
207さんの言ってたことに近かったんでしょうか。
Slony1をアンインストールして、
その後pg_dumpallでバックアップ取る
8.2をインストールしてリストアしてから
再度Slony1をインストールとやって動かせました。
バージョンアップと冗長化一緒にやるのって
えらいめんどくさいものなんですね。。。
250:NAME IS NULL
08/02/15 10:24:41
BOOL型をINT型に変換するような関数はありませんか？
251:NAME IS NULL
08/02/15 14:05:07
どういう状況で使うか分からんが、case文でやっちゃってみてはどうか
252:NAME IS NULL
08/02/15 20:38:59
単にキャストすれば？
=# SELECT true::integer, false::integer;
int4 | int4
------+------
1 | 0
253:NAME IS NULL
08/02/18 10:36:27 lPcRZOP6
2回レコード全体を検索するのは無駄なので、count(*) でレコードを数えるのとレコードのデータ取得を同時にやる方法ってないでしょうか
PostgreSQLは8.2.6、PHP5.2.4から操作しています
なるべくDB側の機能を使って対処したいです
254:NAME IS NULL
08/02/18 12:34:23
>>253
pg_numrowsでは駄目？
255:NAME IS NULL
08/02/18 12:53:54
>>254
それだとoffset limitで指定した区間のレコード数しか出ないので
全件中○～○という風に表示するために総レコード数を数えたいのです
あとPDOでやってます
256:NAME IS NULL
08/02/18 22:28:09
>>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
08/02/18 22:55:50
>>255
よくわからないけど、こんな感じとか？
select
code as コード,
hinmei as 品名,
(
select
count(code)
from syohin
) as 総数
from syohin
where
code=1
258:NAME IS NULL
08/02/18 23:08:14
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
08/02/18 23:10:13
>>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
08/02/19 11:54:27
>>259
それでいいのですが、whereでの条件が多くなると遅くならないのですか?
検索結果をキャッシュとかしてるのだったら問題ないのですが
261:NAME IS NULL
08/02/19 13:04:45
>>260
心配だったら検索結果をtemporary tableにでもキャッシュしてみたら？
262:NAME IS NULL
08/02/20 04:24:26
>>260
詳しくないので、遅いかどうかはわかりませんが、
1つのテーブルで100万レコードからの抽出だと、
1秒ちょっとで、抽出できます。
263:253
08/02/20 14:03:53
気にするほどの付加増ではないようなのでサブクエリでやってみます
temporary tableとの比較もそのうちやってみたいと思います
ありがとうございました
264:NAME IS NULL
08/02/21 06:15:23
vacuum verbose analyzeで出力されるログをjdbcで取得する方法はありますか？
javaプログラムからvacuum実行して結果を管理画面とかで確認したいのですが。
postgres.confでinfoログも出力するように設定してログファイルを
見に行かないと駄目？
265:NAME IS NULL
08/02/21 10:31:42
BOOLをINTに変換する関数はありませんか？
TRUE→1
FALSE→0
MySQLではBOOL+BOOLでINT型に自動変換されますが、PgSQLでは変換されません
266:NAME IS NULL
08/02/21 11:43:35
>>265
>>250-252じゃいかんのか？
267:NAME IS NULL
08/02/21 11:44:18
case文使うか関数作る方が調べるより早いと思う。
268:265
08/02/21 11:49:28
うお、ちょっと前に同じような質問がっ！
ありがとうです
269:NAME IS NULL
08/02/21 22:49:06
> MySQLではBOOL+BOOLでINT型に自動変換
キモすぎる…
270:NAME IS NULL
08/02/22 00:43:47
VBとCを両方やったのでFA:LSEが0か‐1か今一得心が行くことがないのでcase文で対処
271:NAME IS NULL
08/02/25 09:33:31
1000万件ほどのある行から全文検索を行いたいんだけど何かお勧めない？
`tbl1` || `tbl2` || 'tbl2' … `tbl10` LIKE '%検索ワード%' とかだと、検索結果まで数秒～数十秒まで時間がかかってしまうことがあります。
272:NAME IS NULL
08/02/25 15:49:29
単一テーブルでLIKE '%検索ワード%'ならもうどうしようもないんじゃないかな。
Oracle+Times10にするとか、そこだけ全部メモリに持つかしないと。
つかうちだと500万件のテーブルをselect count(1)するだけで70～90秒くらい
かかるんだけど、1000万件でそれなら優秀なんじゃない？
ちなみにshared_buffer増やしても、検索したoidに対応するレコードがキャッシュに
あったら引っ張ってくるだけで、select countには意味ないんだよね？
273:NAME IS NULL
08/02/25 16:40:51
>>271
tsearch2というのがあるらしい。
274:NAME IS NULL
08/02/25 22:18:39
googleのアプライアンスサーバでも導入するほうがよいんでは？
275:NAME IS NULL
08/02/26 04:10:08
プログラムロジックを介さず、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
08/02/26 07:37:02
>>275 nを厳密にしたい目的はなに？
表現の曖昧さを避けるだけなら、冗長化した形で CHECK(一方のチームID < 他方のチームID) とか。
チームIDで検索したいだけなら GIN 使う手もあるし。
277:NAME IS NULL
08/02/26 08:35:01
>>275
チームIDはチーム情報のマスターに格納してあるんでしょ？
278:NAME IS NULL
08/02/26 14:54:48
>>276
まさに、その何かの試合に関するテーブルを作ろうと思ってまして、
その際必ず試合1に対してチームが2になります。
カードを外に出したいのは、集計のためだったりします。
あるチームを基点に試合を検索する場合、一方か他方かがそのチームで、
検索されたデータからもあるチーム以外のチームを見つけなきゃいけない、
というのが面倒な気がしました。
一方外に出しておけば、おそらくクエリだけでなんとかなります。
検査制約とか配列を使うのはアリかもしれません。
ありがとうございます。
>>277
明示しませんでしたが、チームIDはチームテーブルのPKです。
279:NAME IS NULL
08/02/26 14:57:34
>>278
サッカーなんて単語が出てたから、PKってそっちの方かと思ってたよ。
いや、なにやらごちゃごちゃ書いてあったから詳しくは読んでないんだけどね。
280:NAME IS NULL
08/02/26 15:32:19
ソフトのロジックが複雑でも、
テーブル設計は、標準的でシンプルなほうがいいかもね。
メンテなどしやすい方が便利な事が多い。
281:NAME IS NULL
08/02/26 21:47:49
>>271
>>273
tsearch2よりはludiaの方がいいんじゃないか。
tsearch2は形態素解析。ludiaはN-gram。
形態素解析だとLIKE %% と違った結果になるぞ。
282:NAME IS NULL
08/02/26 23:00:26
LIKEやN-gramなら漏れが無いってわけでもないので、
割り切れるならば形態素解析も使いどころはある。適材適所で。
283:NAME IS NULL
08/02/26 23:54:36
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
08/02/27 00:33:16
>>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
08/02/27 01:51:48
>>284
丁寧な解説＆ご指摘ありがとうございます。
どこで使うかをわかっていないせいで、知識がごちゃ混ぜになってたんですねorz
一からきちんと勉強しなおします。ありがとうございました。
286:NAME IS NULL
08/02/27 15:48:47
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
08/02/27 17:03:48
プラグインのデバッガじゃね？
288:NAME IS NULL
08/02/28 00:26:16
>>286 PL/pgSQL のデバッガだったはず。
使わないなら単なるリソースの無駄なので外すべし。
289:NAME IS NULL
08/02/28 00:41:09
plpgsqlのデバッグって出来たんだ……！
290:NAME IS NULL
08/02/28 13:47:48
pgpool使用時に、100回に1回くらい通常時1秒程度のplpgsqlによるストアドの返答に
数十秒、長いときだと数分かかるんですが、原因がまったく検討つきません。
アクセスは一秒数回ありますが、autovacuumの実行なども発生には関係ないようで
一度killしてから同じSQLを走らせると1秒程度で終わります。
また、ストアド実行中に同じストアドを別の引数で呼び出しても、全く問題なく実行できます。
ストアド自体にはみたところ問題はありません。
原因や解決策などに心当たりがございましたら、ご教示ください。
291:NAME IS NULL
08/02/28 14:45:33
自分は、詳しくないので見当つきませんが、
アドバイスを受けるのでしたら、
少なくとも、バージョンや環境は提示した方がいいでしょう。
292:290
08/02/28 14:49:09 NWie+e5y
申し訳ありません。
FreeBSD6.3、amd64
PostgreSQL8.3
pgpool-II version 2.0.1
です。
また、稼動を続けるとCPU使用率が増加していき、postgresを再起動すれば治ります。
293:NAME IS NULL
08/02/28 15:09:55
負荷が高くなっていくのは、運用では困りますね。
原因が見つかるといいですね。
8.2.x など旧バージョンと比較して試してみるのはどうでしょうか。
294:NAME IS NULL
08/02/28 18:03:40
8.3もpgpoolII 2もまだまだ枯れていないからなぁ。
295:NAME IS NULL
08/02/29 00:52:01
>>290
問題を切り分けるのに、PostgreSQLだけで同じ事象が
発生するか試したら？
296:NAME IS NULL
08/02/29 13:45:44
そうだな。pgpool切り離しと、ネットの影響もあるからlocalhostだけでやるのも
297:NAME IS NULL
08/02/29 21:16:15 sA1ohjpH
ファイアウォールとＳＥＬＩＮＵＸを切ってみては？あとは
ＰＨＰとかから呼んでるなら、永続的な接続を使ってると色々
リソースを食い続けるので、非永続で。ＣＰＵ使用率はpostgreSQL
が使ってるのかな？ ８．３に興味あるけど、まだ怖いね。
pgpool-II Ver 2は、こういった分野のソフトにしてはバグが多い印象。
ver 1 を使ったほうがいいかもww
298:290
08/03/01 21:56:32
すみません、SQLを改善したら解決しました
問題きりわけのためにplpgsql内のWHERE条件を分割して実行したところ
再発しなくなりました。
元のSQLが間違ってたようには思えないのですが…
pgpooｌをはずして、4BSD、ULEどちらのスケジューラーでも試しましたが
問題はpostgresql単体の問題のようです。
299:NAME IS NULL
08/03/01 22:12:52
時間かかった時は不適切な実行計画が選択されちゃってたとか？
300:anonymous
08/03/02 08:06:09
>>298
よかったですね。
旧バージョンでは問題なくても、
新バージョンで問題が発生する場合もあると思います。
301:NAME IS NULL
08/03/02 12:58:39 4NEnxdcC
>>298
参考のために、オリジナルと分割後のSQLを教えて。
もしPostgreSQLのバグなら、誰かが対処してくれるかもしれないし。
302:920
08/03/02 22:09:11
調査を続けていたところ、NULLが絡んだときにSQL自体が
PERFORM 1 FROM target_table
になっている場合があることに気がつきました。
これの応答に時間がかかっていたようです。
お騒がせしまして申し訳ありません。
SQL間違いとはお恥ずかしい…
303:290
08/03/02 22:11:26
すみません、920ではなくて290です。
304:NAME IS NULL
08/03/02 22:22:55
URLﾘﾝｸ(www.postgresql.jp)
> 重要なお知らせ：
> 2月24日にwww.postgresql.jpサーバが部外者によりクラックされていた事が判明致しました。このため、サイトは安全な別サーバに移動し、トップページのみ表示されるようになっています。
> 現在、復旧作業中です。今のところルート権限を取得された形跡は発見されていません。 詳しい情報は後日公開致します。
> ご迷惑とご心配をお掛けする事をお詫びいたします。
305:NAME IS NULL
08/03/03 14:31:40
うわぁ…
postgresql.jp って、SRAが事務局でサーバも提供してたのは、もう昔の話?
306:NAME IS NULL
08/03/04 16:38:38
うげ、8.3って数値から文字列の暗黙の型変換がされないのか。
怖すぎてアップグレードできん。
307:NAME IS NULL
08/03/04 16:49:33
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
08/03/04 22:44:35
>>306
そんな怖くないだろ
309:NAME IS NULL
08/03/04 23:52:04
>>306
俺はchangelogを読まずに酷い目に遭ったぜ・・・orz
310:NAME IS NULL
08/03/05 12:00:43
>>308
どの言語出身かで分かれるだろうなｗ
311:NAME IS NULL
08/03/05 19:44:44
もともと date_column = 2008-03-01 っていうミスをしたという話があって、
date_column::text = (2008-03-01)::text = 2004::text
と解釈されるのはまずいとして、暗黙の型変換は削られたらしい。
ミスらないためには悪くは無いと思うけどね。
必要なら自分でキャスト追加すればいいだけだし。
312:NAME IS NULL
08/03/05 23:06:59
質問させてください。
pg_dumpall でデータベース全体をバックアップした後、
このデータを元に、部分的な復旧を行う事は可能ですか？
手元に pg_dumpall で取ったデータしかなくて、
それを別サーバに復元したいのですが、
全部ではなく一部分だけ復元したいです。
調べた所、丸々復元する方法は見つけたのですが、
部分的な復元方法を見つける事が出来なかったので
よろしくお願いします。
313:NAME IS NULL
08/03/06 02:54:14
部分的な具体例を示した方がいいと思います。
テーブル単位なのかレコード単位なのか、
カラムや部分文字列なのか。
314:NAME IS NULL
08/03/06 03:00:03
>>312
バックアップ時のオプションにもよるだろうけど
バックアップされたファイルは基本的にテキストファイルだから
必要な部分だけに加工してrestoreするか
一時的にどこかに全てrestoreして、必要な部分だけ
個別にpg_dumpし直すか、だね。
315:NAME IS NULL
08/03/06 10:20:23
なんかCLUSTER発行しても並べかえてくれない気がするんだが…
バージョンは8.2.6で
316:NAME IS NULL
08/03/06 16:33:27
ローカルでpgsql立てて全部入れてから改めて必要な部分を戻せばよいのでは
317:NAME IS NULL
08/03/06 23:29:33
質問です。
カラムの並び順を変えるには、この方法しかないのでしょうか？
テーブル 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
08/03/07 00:41:47
無いんじゃないかなあ
そういう時はテーブル丸々コピーして、新しい並びで空のテーブル作って
select insertで一括挿入っていうのをよくやるけど
319:NAME IS NULL
08/03/07 08:09:12
VIEW 使えば？ そもそもRDBMSでカラム順に依存したSQLを書くのが間違い。
320:NAME IS NULL
08/03/07 10:36:16
うん、俺もVIEW使うのが正解だとｵﾓ。
>>319の言うことは正論。
321:NAME IS NULL
08/03/07 10:51:18
>>317
純粋に、なぜ列の並び替えが必要になるのか知りたい。
322:NAME IS NULL
08/03/07 11:07:36
select * from tabの結果が気持ち悪いからじゃないの？
俺も後からカラムを追加するときに、一番最後じゃ気持ち悪いときが結構ある。
323:NAME IS NULL
08/03/07 11:33:34
>>322
気持ち悪いのは人だけでしょ。
プログラムを実行するコンピュータには何の関係もない。
324:NAME IS NULL
08/03/07 14:16:29
>>322
つか*で取るからそういうことになる。
列指定汁ｗｗｗ
325:NAME IS NULL
08/03/07 14:46:23
>>323 実行する人の精神衛生状態は作業効率に直結する
326:NAME IS NULL
08/03/07 14:48:26
>>325
なんて言っている人の作業効率なんてたかが知れている
327:NAME IS NULL
08/03/07 14:52:24
すんません、vacuumに関して教えてくださいな。
vacuum -a -f -zは毎日夜中に一度やるとして・・・
・オンライン中にvacuumしていいのですか？
（極端に遅くなるとか、壊れる等はありますか？って意味が一番強い）
・いいのであれば、vacuumのオプションは何が最適かしら？
土日は更新メイン。平日は参照メインなシステムです。
バージョンは、8.2.6です。
よろしくお願いします。
328:NAME IS NULL
08/03/07 14:57:09
MyISAM の ORDER BY 無しのデフォルトの並び順での取り出しは、
確かに挿入順であって結構速い気がする。
この動作に依存して組む人たちもいるんじゃないだろうか。
329:NAME IS NULL
08/03/07 15:02:16
>>328
それ行の話でしょ？ いま問題になっているのは列の並び
330:NAME IS NULL
08/03/07 18:19:48
vacuumは遅くなるから夜中にやってるなら
それで良いと思うけど。
うちは随時更新、参照入るシステムだけど、
処理重い時間にvacuumやると結構やばい。
vacuum１回で足りないと感じるのは何故だろう？
メモリが十分にあるならチューニングしたらどう？
URLﾘﾝｸ(www.thinkit.co.jp)
autovacuumはどうなのか知らん
331:NAME IS NULL
08/03/07 19:56:07
世の中にはソースのないプログラムとかもあるからなぁ。
データベースの列の並びがちがうだけで動かなくなる糞プログラムなんかに限ってソースが無かったりする。
俺は今またそれに引っかかったよ。 ｏｒｚ
332:NAME IS NULL
08/03/07 23:47:46
そんなプログラムにこそ、カラムの挿入なんてやったらダメなんでは。
333:NAME IS NULL
08/03/08 09:12:47
>>327
vacuum -a -z だけで十分。
VACUUM FULL は必要ないよ。
オンライン中の VACUUM で DB が壊れることはないし、
極端に遅くなることもないけど、負荷が気になるなら
vacuum_cost_delay とか VACUUM のコストを弄ってやればいい。
334:NAME IS NULL
08/03/09 01:19:17
create table hoge( foo integer not null );
create table fuga( bar integer not null check( bar < foo ) ) inherits( hoge );
こんな感じに継承元と先とでの数値の検査制約って出来ないんだっけ？
335:NAME IS NULL
08/03/10 23:45:35
>>334 まったく問題なくできるようだが。
336:327
08/03/11 14:16:00
>>330,333
ありがとう。
>vacuum１回で足りないと感じるのは何故だろう？
うーん、一個件数の多いテーブル（100万件ぐらい）があって、
そこが土日の更新の対象で且つ、結構他のテーブルとjoinしてるんですよ。
一応、explainで見て、indexの見直しと対象SQLのチューニングをして、
大分早くなったんだけど、１年で100万件程度増えるので、
いつかはまた遅くなるんだろうと感じてます。
なので、手軽？に早くする手法はないかと調べていた訳です。
オンラインのVACUUMで壊れないのであれば、
一度負荷と相談して試して見ます。
ありがとさんでした。
ところで、V8.x系のメモリチューニングで、1GB以上共有メモリを取っても、
メモリマネージメントの都合で逆に遅くなるってあるんだけど、
やっぱりそういう物なんですかね？
サーバー4GBにしたのに無駄？
337:NAME IS NULL
08/03/12 00:35:41
>>336
パーティショニングすれば？
> サーバー4GBにしたのに無駄？
共有メモリ以外はOSキャッシュとして使われるから、
まったく無駄にならん。
338:NAME IS NULL
08/03/12 19:51:58
>>337
レスありがとう。
パーティショニングを今度試してみるダス。
日々の売り上げデータに近い構造なので、
効果は大きそうな気がします。
大抵の集計自体も長くて３ヶ月ぐらいだし。
ありがとうございました。
339:NAME IS NULL
08/03/13 00:47:20
共有メモリ１Ｇ以上だと遅くなるのってどっかに書いてある？
340:NAME IS NULL
08/03/13 08:07:54
> 共有メモリ１Ｇ以上だと遅くなる
というよりは、単に増やせば増やすほど速くなるわけではないってこと。
DB/OS 2層でキャッシュするよう設計されているから。
他のデータベースでも似たようなことはよくある。
341:NAME IS NULL
08/03/13 19:38:18 RTgKtkUI
>>339
8.1のチューニングのページに書いてあった気がします。自分の8.1
での経験ですが、２０Ｇとか指定すると、小さなテーブルのdrop table すら
１秒くらいかかった記憶が、、、。
>>338
おなじく8.1での話ですが、パーティショニングしたテーブルをjoinす
ると、selectがシーケンシャルになって激遅になるケースがありました。
同じ構造で同じＳＱＬでも8.3はインデックスを使ってくれるんですけどね
342:NAME IS NULL
08/03/13 20:43:28
>>341 たしかに drop table は遅くなるかも。メモリ全部舐めるから。
drop table を高速化する目的でチューニングすべきかは疑問だが。
343:NAME IS NULL
08/03/14 00:29:37
temp tableしまくるなら効果ありそうだなｗ
344:NAME IS NULL
08/03/14 01:03:30
>>341
> ２０Ｇとか指定すると、
実メモリはいくら積んでたの？
345:NAME IS NULL
08/03/14 01:19:18
>>343 temp table はローカルバッファなので関係なかったりする。
346:NAME IS NULL
08/03/14 09:25:11
>>339
URLﾘﾝｸ(itpro.nikkeibp.co.jp)
ここ以外にも、具体的な数値を上げて書いてあったところが
あったと思うけど、おもいだせませんでした。
347:NAME IS NULL
08/03/14 23:16:26 gKUPvhD2
drop table だけじゃなくて、delete して insert する処理も、もっさり感が
ありました。０コンマ何秒の処理だったけど、共有メモリ１．５Ｇ設定時の
２倍くらいの所要時間だったイメージ。ＤＢ全体のサイズは６Ｇ程度です。
>>344
会社のサーバなので、たしか３０Ｇ台でした。
348:NAME IS NULL
08/03/15 07:58:18
>>347 そんな豪勢な環境はめずらしいからなぁ。
共有メモリ20GBなんて大きな設定は、テストが足りてないのかも。
4GBを超えるとちょっと心配だな。
あまらせてもOSがキャッシュとして使うから、無駄にはならないし。
349:NAME IS NULL
08/03/16 01:45:48
>>313>>314>>316
亀レスすいません。
>>316の方法で行く事にします。
どうもありがとうございます。
350:NAME IS NULL
08/03/17 21:50:44
数百万件以上など、どんどん増えていくテーブルに対して遅くなっていく場合の対処ですが、
日付で管理できるテーブルなら、
例えば、
今月とそれ以前のテーブルに分割してみるとかは？
バッチでレコードの移行を行う必要が出たり、
プログラムの変更が必要になりますが。
その場合、veiwで対応ということが考えられますが、
例えば、レコードが少ないテーブルAとレコードが多いテーブルBの連結を記述しているveiwの場合、
テーブルAにINSERTなど変更が加わる際、
veiwのレコードが多いテーブルBの影響を受けて、多少遅くなるということはあるのでしょうか？
あったとしても、気になる程度じゃないのかな？
351:NAME IS NULL
08/03/17 21:53:17
veiw
352:NAME IS NULL
08/03/17 22:03:59
失礼。よく間違えるんですよ。(^^;
353:NAME IS NULL
08/03/17 22:18:35
>>350
千万件ぐらいならclusterかければ直ぐに結果返ってくるよ
一億件は試した事ないから判らんｗ
354:NAME IS NULL
08/03/17 22:30:52
>>353
ありがとうございます。
やったことはないので、試してみます。
現在、Group by など複数のSQLを一度に発行しているので、
それが完了するのに、20～30秒くらいかかっています。
さらに早くなるとストレスなくなるなぁ。
355:NAME IS NULL
08/03/17 22:32:28
view って、select など、参照する時だけにしか使用されずってことで、
insert や update には、全く影響はないのかな？