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 には、全く影響はないのかな？
356:NAME IS NULL
08/03/17 22:34:53
あ、view って、insert 時など、キーの重複などの整合性をチェックしてたっけ？（＾＾；
なんか、そんなことがあったような。。。
357:NAME IS NULL
08/03/18 18:30:33 cmzwaPqX
pgpool3.2のバグで、FreeBSD4.11上でmakeできないらしいので
3.1.2を入れようと思うのですがどこかでげとできますか？
bugfixした3.4.1をmakeることも考えたのですが、稼動中のサーバに
突っ込むので開発版は避けたいところです。
358:NAME IS NULL
08/03/18 19:18:39 1so+byeI
8.3.1 & 8.2.7
359:NAME IS NULL
08/03/19 04:27:00
>>350
適切なindexを介してアクセスする場合は対数オーダーだから、それが可能ならば
1テーブルで済ませる方が絶対有利。
どうしてもfull scanが必要となる処理ではテーブル分割も考えられるが、
union viewを使う場合、ちゃんとプランナがそれを認識してあらかじめ不要な
テーブルを実行計画から除外することが出来ないとかえって遅くなる。
360:NAME IS NULL
08/03/19 08:04:05
>>359
削除のことも考えた方がいい。
テーブルを分割する最大のメリットは、古いデータの一括削除だから。
絶対に削除しないならば、確かに分割する利点は薄い。
361:NAME IS NULL
08/03/21 02:39:37 bZgunjjY
www.postgresql.jp 繋がらない(´･ω･｀)
362:NAME IS NULL
08/03/21 02:53:43
>>361
未確認情報だけど、またクラックされたから復旧中らしいよ。
363:NAME IS NULL
08/03/21 05:06:01
>>362
その話がMLに流れたって、スラドのアレたまで見たよ。
364:NAME IS NULL
08/03/21 16:07:05
>>359-360
どうも。
１テーブルだと、どんどん増えて数百万レコード件以上になり、
１画面の表示に２０～４０秒はかかってしまいます。
分割すると、数千レコードなので、１～２秒以内で終わります。
将来は数千万レコードにもなり、もっとかかってしまいます。
ひとつのSQLで済むまない１０以上のSQLの処理を行っている情報てんこ盛り画面なので。。。
365:NAME IS NULL
08/03/21 20:59:17 3PY9kdIC
>>364
数千レコードで１～２秒の処理って、、、どんなＳＱＬなんでしょう？
処理範囲分のデータを一時テーブルに取り出して使えば、それで
速くなったりはしないですか？
366:NAME IS NULL
08/03/22 15:18:52
>>364
正規化されていないってオチじゃないよね？
複雑なデータ取得でカーソルすら使ってないとかだったら
単純に技量不足だと思うよ
367:NAME IS NULL
08/03/23 01:51:18
>>365-366
どうもありがとうございます。
>>365
合計で１～２秒ですから、
ひとつのSQLで、0.1秒～0.2秒以下ということですが、それでも遅いですかね？
ほとんど全部が、Group by 使用のSQLです。
一時テーブルへ抽出ですか。
普通のテーブルへInsertでしょうか？
その方法はメモリなど特殊な方法でしょうか？
一時テーブルへ抽出しても、複数同時アクセスが頻繁にあるので、
同じテーブル利用にならないよう個別利用になるよう考慮する必要があります。
同じテーブル利用で重複しても数万レコードですから、
Delete & Insert が早ければ、効果あるかもしれません。
しかし、頻繁に画面更新を行うので、Insertが多くなり、意味があるかどうか。
頻繁にバキュームしないといけなくなるのかな？
>>366
カーソルは使っていません。
カーソル利用とSQLでどのくらいの差があるのか知りませんが、
１０倍以上と劇的に早くなるようでしたら、今後検討してみますが、
はっきり言って、管理と工数のことを考えると面倒ですね。
ただ、カーソル制御はわかりますが、
SQLをどう、カーソル使用で置き換えて利用するのか、勉強不足で、わかりません。
正規化とは、どの意味で、言われているかわかりませんが、
PostgreSQL固有で言われるものでしたら、正規化はしていません。
もちろん、冗長データはありません。
368:NAME IS NULL
08/03/23 03:00:03
>>365-366
次に、ひとつのSQLを紹介します。（改行が多いので）
テーブル名やカラム名は、変えていますが、
生のSQLです。
まだ未熟なので、SQL自体を見直す点もあるとは思います。
テーブル詳細を紹介できないので、わかりづらいと思いますが、
table001が１００万レコード以上で、
約、1.2秒～2.0秒かかります。
数千レコードでしたら、
0.2秒前後です。
このようなSQLが１画面に１０以上あると合計、２０～４０秒以上になってしまうので、
よく使う該当レコードをテーブルを分割して数千レコードにすると、合計１～２秒で収まります。
テーブル設計自体やインデックスの見直し、チューニング次第でまだ高速になるのは間違いないと思いますが、
将来的に、数百万、数千万レコード以上になる前提では、
テーブル分割で１～２秒の現在と同様に早くなるとは思えないので、検討もしていない現状です。
369:NAME IS NULL
08/03/23 03:01:30
（改行が多いので続き）
------------------------
select
case
when ee.kbn001='' then ''
when ee.kbn001='1' then '区分1'
when ee.kbn001='2' then '区分2'
when ee.kbn001='3' then '区分3'
when ee.kbn001='4' then '区分4'
when ee.kbn001='5' then '区分5'
else null
end as kbn001,
case
when ee.kbn001='2' then ee.kbn002
else 'kbn002'
end as kbn002,
aa.name as 名称,
aa.kana as カナ,
aa.tel,
case
when cc.flg001=1 then 'フラグ1'
when cc.flg001=2 then 'フラグ2'
when cc.flg001=3 then 'フラグ3'
when cc.flg001=4 then 'フラグ4'
when cc.flg001=5 then 'フラグ5'
else null
end as flg001,
case
when aa.kbn003='0' then '区分30'
when aa.kbn003='1' then '区分31'
when aa.kbn003='2' then '区分32'
else null
end as kbn003,
'' as dummy,
dd.sum_kei as 計,
translate(aa.biko,'
',' ') as 備考,
bb.jun as 順番,
bb.code01 as コード
370:NAME IS NULL
08/03/23 03:02:06
（改行が多いので続き）
------------------------
from
(
select
min(jun) as jun,
code01
from table001
where
code002 =6
and translate(to_date(data001,'yyyy/mm/dd'),'-','/')='2008/03/21'
group by
code01
) bb
left join data002 aa
on (aa.code01=bb.code01
)
left join data003 cc
on aa.code01=cc.code01 and cc.code002 =6
and translate(to_date(cc.data001,'yyyy/mm/dd'),'-','/')='2008/03/21'
left join
(
select
code01,
coalesce(sum(kingaku001),0) + coalesce(sum(kingaku002),0) as sum_kingaku001
from table001 aaa
where
aaa.code002 =6
and translate(to_date(aaa.data001,'yyyy/mm/dd'),'-','/')='2008/03/21'
group by
code01
) dd
on aa.code01=dd.code01
left join table003 ee
on (aa.code01=ee.code01 and ee.code002=6)
order by bb.jun
------------------------
371:NAME IS NULL
08/03/23 08:41:01
>>369-370
これじゃ遅いだろうね。
code002のカーディナリティが低くてdata001に関数インデックスも
設定していないなら、そのクエリは table001 の seq scan が発生
するというのはわかるかな？
検討する気もないんだったらどうでもいいが。
372:NAME IS NULL
08/03/23 09:38:31
> translate(to_date(data001,'yyyy/mm/dd'),'-','/')='2008/03/21'
「関数(列) = 定数」の書き方ではインデックスが使われない。
data001列をdate型に置き換えて date001 = '2008/03/21' か、
timestamp型なら '2008/03/21' <= date001 AND date001 < '2008/03/22' にするか。
一般的な方針としては、文字列型を減らす（意味にあう他の型を使う）のが良い。
373:NAME IS NULL
08/03/23 10:16:54 YDmnE8vH
>>367
一時テーブルですが、
create template(?) table *** as select * from table001 where ***
とかで、必要な範囲のtable001のデータを持った一時テーブルをメモリ上に
つくれます。他の接続とは干渉しないので、複数処理とかは気にせず
でＯＫ。delete も必要ないです。pgpoolとか使ってるなら、使用後に dropが必要。
んで、一時テーブルを使って処理すれば、とりあえず簡単に速く
なると思うけど
374:NAME IS NULL
08/03/23 11:35:59
>>371-372
ありがとうございます。
文字列だと遅くなるのは、認識していますが、
「関数(列) = 定数」だと、インデックスが使用されませんか。
考えてみると、そうですよね。致命的欠陥ですね。
date001 = '2008/03/21'
の書き方にすると、４倍ほど早くなり、1.2秒が、0.3秒ほどになりました。
まずは、データの統一整備をして、
translate(to_date(data001,'yyyy/mm/dd'),'-','/')='2008/03/21'の記述をやめ、
date001 = '2008/03/21'の記述にしようと思います。
データ型の変更は、時期を見て検討しようと思います。
>>373
ありがとうございます。
簡単にメモリ上にできるのでしたら、時期をみて試してみようと思います。
pgpoolは使用していません。今のところも予定はありません。
375:NAME IS NULL
08/03/23 13:50:33
>>374 の補記
>致命的欠陥ですね。
は、私の設計、SQLが欠陥という意味です。念のため。
376:NAME IS NULL
08/03/24 12:50:57
>>375
大丈夫。その意味が分かる人間ならクエリを見た時点で分かっていると思うぞ。
まあ何だ。頑張れ。
377:NAME IS NULL
08/03/26 20:53:54 HwJR8fjT
LEFT JOINでの結合に関する質問です。
頭の中でごちゃごちゃやる分には、
結合の順番によって内部処理のコストが大分変わりそうですが、
PostgreSQLの実際の作業としては、
SQL最適化した上で実行されるから関係ないのでしょうか？
（実際はもっと複雑ですが）
例えば以下のようなSQLでtable_a、table_b共に数百万件あったとします。
数百万件を結合した上で、table_bで絞り込むより、
table_bで絞り込んだ後にtable_aを結合した方がコストがかからないような場合です。
SELECT *
FROM table_a
LEFT JOIN table_b
WHERE
table_b.id=1;
378:NAME IS NULL
08/03/26 21:07:32
>>377
explain してみるといいのでは。
379:NAME IS NULL
08/03/27 10:42:10
360万件のテーブルAをselect count(1) するのに
85秒もかかっていて悩んでいます。別の730万件のテーブルBは11秒でした。
テーブルAデータ量は1GBは超えていると思います。テーブルBは数十MBくらい。
環境:
OS:Linux(FC7)
PostgreSQL8.3
Core Duo@2.66GHz
Mem:4GB (認識は3.6GB)
設定
shared_buffer 1500MB
work_mem 256MB
shared_bufferは大きくしすぎても遅くなるとかの情報があったのですが、
なんか速くする設定とかありますか？
380:377
08/03/27 16:11:25 tPBRhLWv
>>378
explainの結果をどう見たらよいのか良く分からなかったのです(DB毎に違い過ぎますよね)。
検索していたらよさげな情報を見つけたので、explainしてみます。ありがとうございます。
SQLiteやMySQLのexplainよりも実用的なようですね。
>>379
primary key をはっていないのでは？？
381:NAME IS NULL
08/03/27 22:12:57
>>379
単にテーブルサイズが大きくて、ディスク読み込みが大量に発生しているからでは？
キャッシュに乗った後の速度で良ければ、synchronize_seqscans = off を試してみると良いかも。
他に、更新を繰り返したせいでテーブルが太っているならば、
いったんCLUSTERなりVACUUM FULLなりをかけてみるとか。
>>380
何の効果も無いぞ > primary key
382:NAME IS NULL
08/03/27 23:54:21
すいません8.2.5でした
>>381
synchronize_seqscans = offは試してみます。と思ったけど8.3からなのかな。
ディスク読込のせいなのはほぼまちがい無いんだけど、shared_buffers割り当てを
増やしてもほとんど解決しなかった。もしかしてpostgresのキャッシュって、
queryでoidを読み出して、そのoidに対応するデータがキャッシュされてれば
キャッシュを見るだけなんじゃないのかなあと思ったんだけど、それで合ってる？
そう考えるとメモリはOSのディスクキャッシュに回した方がいいんじゃないかなとも
思ったんだけど。
vacuum fullは一回途中までかけたんだけど、20分くらい返ってこないのでやめた。
365d24hサービス中なので厳しい。vacuum analyzeは毎日かけるようにしたけど。
383:NAME IS NULL
08/03/28 01:14:47
365日24時間稼動しているなら、
まずは、テストできる予備機は必要ですね。
あとはサーバーの再起動とか。。。
365日24時間稼動で、それも不可能ならメンテ期間しか無理ということになりますね。
384:NAME IS NULL
08/03/28 08:18:06
>>382
ぜんぜんちゃう。oidなど使わない。
テーブルBの「数十MBに11秒」でもものすごく遅いので、環境がおかしい気がする。
100MBで10秒ならば、1GBで100秒かかるのも仕方ないでしょ？
あと、VACUUM FULLはアホのように遅いので、やるならCLUSTER。
385:NAME IS NULL
08/03/28 17:00:26
>>383
予備機はあるけどスペックが違うので大分遅いんです。
本番データは2GB強あるのでインポートするのも一苦労だし
>>384
そうなんだ。じゃあshared_buffersを全データが載るくらい増やせば
劇的に速くなると思うんだけど、postgresql8でも1GBくらいに性能ピークが
あるっていうのはなんでなの？
>100MBで10秒ならば、1GBで100秒かかるのも仕方ないでしょ？
select * じゃなくて select count(1)だから容量では単純比較できないと思う。
730万件が11秒ってなかなか優秀だと思ってたんだけどものすごく
遅いん？うーん。このスペックなら何秒くらいが妥当だと思う？
数十万件のテーブルから複雑な検索条件で検索かけるのとかは
軒並み1秒以内で終わるし、テスト環境(これもLinux)にくらべたら大分速いから、
環境のせいじゃないと思ってたんだけどなあ。
386:NAME IS NULL
08/03/28 21:02:35
見当外れなこと書いてたらスマソだが、
select count(*)にはできないのかな？
Postgreは知らんけどOracle8iではえらい差がでるよ。
count(1)ではDistinctのカウントになるので重複値の検出でえらい時間がかかる。
全件count(1)なんてやっちゃうと全件の中間テーブルを作ろうとしたりして。
387:NAME IS NULL
08/03/28 21:08:15
>>385 730万件が11秒
手元の環境だと、2秒未満。一昔前のデスクトップ機。
730万件だと最低250MB以上にはなるはずだし、なにか勘違いしてないか？
=# select pg_size_pretty(pg_relation_size('test'));
pg_size_pretty
----------------
252 MB
(1 row)
=# select count(1) FROM test;
count
---------
7300000
(1 row)
Time: 1876.152 ms
388:NAME IS NULL
08/03/28 21:09:22
>>386 残念だが見当外れ。
count(*)とcount(1)はまったく同じ動作です。
389:NAME IS NULL
08/03/28 22:28:14
>>388
あれ？同じ動作だったんだっけ？
昔なにかでcount(*)よりcount(1)の方が良いって記事をどこかで見た気がするんだが・・・。
勘違いか？
390:NAME IS NULL
08/03/28 22:51:29
>>387
ごめんそのpg_size_prettyを知らなくて、データのバイト数(1レコード36バイト)に
730万をかけて20～30ＭＢかなあと思ったんだけど、一桁間違えてた。
それやってみたら485Mだったよ。
360万件の方は3587MB
トータルのデータ領域が広すぎて遅くなってんのかな。
shared_buffersも1.5GBじゃ全然収まってないってことだね。
サービスインからしばらくVACUUMかけてなかったので、一回くらいは
VACUUM FULLかけたいんだけどね。
CLUSTERは調べたらテーブルロックしちゃうんだね。
夜中やってみるかな
391:NAME IS NULL
08/03/28 23:06:44
>>389
ユニークインデックスを持った列名の方がいいという記述なら見つけた
URLﾘﾝｸ(www.geocities.jp)
URLﾘﾝｸ(oracle.se-free.com)
でもって今日は325万件なんだけどやってみた
1. count(key) 76秒
2. count(1) 65秒
3. もう一回count(key) 63秒
4. selct count(*)が83秒
1の実行でキャッシュに載ったのかな。アクセスが割とある時間帯なので、
別要因で変動しているかも知れないけど
392:NAME IS NULL
08/03/28 23:45:45
>>389
他のDBMSだと効果があるのかもしれないけど、PostgreSQLに関しては関係ないのですよ。
あんまり鵜呑みにしないほうが良いのですよ。
393:NAME IS NULL
08/03/29 20:05:32
見当違いかもしれないが、HDD壊れてると遅くなったりしないか？
394:NAME IS NULL
08/03/30 09:29:37 7s6ei0XY
>>391
マシンの物理メモリ量と、DB全体のサイズの問題なのでは？メモリを
８Gくらいにすれば、あんましHDDにアクセスせずに済んで早くなると
思います
395:NAME IS NULL
08/03/30 09:56:52
>>391
オススメとしては、
・ＯＳをCENTOS、x86_64にしてメモリを８Ｇくらいは積む。
・shared_buffersは１．５ＧのままでＯＫ
・ＨＤＤを高速なものに交換する。
２４時間３６５日について
・VACUUM FULLはロック掛かると思いますので、運用中は難しいかと。
・バージョンによっては、VACUUMがらみでバグがあったと思うので、
結構不安。
8.2系統だと、8.2.7のリリースノートに
Repair potential deadlock between concurrent VACUUM FULL operations
on different system catalogs (Tom)
って載ってるし、バージョンアップをすすめます。
参考
URLﾘﾝｸ(www.postgresql.org)
・ＯＳ再起動も、１ヶ月に１回くらいしたほうが良いのでは？
396:NAME IS NULL
08/03/30 12:38:56
ソフトやハードで力技で解決するよりは、
・VACUUMをちゃんとする運用にかえる
・count()を多用しない設計にする
ほうが重要だと思うのだが・・・
397:NAME IS NULL
08/03/30 15:59:36
8.3にしてVACUUMの必要性をなるべく減らすという手もある。
んまぁ、>>396の言うとおり、時間がかかるからVACUUMはしないというのは
腐った運用としかいいようがないけどね。
398:NAME IS NULL
08/03/31 11:57:27 NLL0Kbcv
テーブルは以下のようになっています。
TableName(
id serial,
up_id integer,
data text,
updatetime timestamp
);
このとき、up_id毎にupdatetimeが最新のものをリストしたいのですが、
どのようなSQL文を書いたらいいのでしょうか？
up_id 指定で1件取り出すだけなら以下のSQL文でいいのはわかるのですが
SELECT * FROM TableName WHERE up_id=? ORDER BY updatetime DESC LIMIT 1;
399:391
08/03/31 12:10:22
みんなありがじゅー。
VACUUM ANALYZEは毎日やってる。最初AUTOにしてたんだけど、
毎日10万レコードくらい追加/削除するのでデイリーでやるようにした。
count()するのは、一覧表示の時にまず全件カウントしてページング処理を
したいから避けられない。
HDDが遅いのはアレだと思ってたので、次のシステムではRAID0+1を提案した。
で、>>395の
・メモリを８Ｇくらいは積む。
・shared_buffersは１．５ＧのままでＯＫ
っていうのは、残りの6GBはOSのディスクキャッシュにおまかせするってこと？
400:NAME IS NULL
08/03/31 12:29:58
>>398
idとup_idの関係がイマイチ分からんのでkwsk
401:NAME IS NULL
08/03/31 12:43:44
>>398
てきとーに、
select up_id, max(updatetime) where tablename
gourp by up_id
と書いてみるテスト