PostgreSQL Part.9

1 ：2012/05/26 〜 最終レス ：2013/09/23

PostgreSQL (ぽすとぐれすきゅーえる, ぽすとぐれす) について語るスレです。
●関連サイト
PostgreSQL 本家
http://www.postgresql.org/
日本PostgreSQLユーザ会
http://www.postgresql.jp/
ドキュメント
http://www.postgresql.jp/document/current/html/
ダウンロード
http://www.postgresql.jp/PostgreSQL
Let's Postgres (ポータルサイト)
http://lets.postgresql.jp/
pgFoundry
http://pgfoundry.org/
●前スレ
PostgreSQL Part.8
http://toro.2ch.net/test/read.cgi/db/1294641578/

2 ：

●過去スレ
PostgreSQL 2テーブル目　(WebProgから派生)
http://pc8.2ch.net/test/read.cgi/db/1056944337/
PostgreSQL ＆ pgsql-jp ML 3テーブル目
http://pc11.2ch.net/test/read.cgi/db/1079771059/
【Windows】 PostgreSQL8　Part.1 【対応】　(実質part4)
http://pc11.2ch.net/test/read.cgi/db/1102247223/
PostgreSQL Part.5
http://pc11.2ch.net/test/read.cgi/db/1196512717/
PostgreSQL Part.6
http://pc11.2ch.net/test/read.cgi/db/1224318817/
PostgreSQL Part.7
http://hibari.2ch.net/test/read.cgi/db/1256300618/
PostgreSQL Part.8
http://toro.2ch.net/test/read.cgi/db/1294641578/
●関連過去スレ
■　　　PostgreSQLのことならここで聞け　　　■　(初心者part1)
http://pc8.2ch.net/test/read.cgi/db/1056960249/
■　　　PostgreSQLのことならここで聞け　　　■　(初心者part2)
http://pc8.2ch.net/test/read.cgi/db/1091523132/
PostgresSQLについて語ろう　(雑談part1)
http://pc8.2ch.net/test/read.cgi/db/1056992724/
PostgreSQLについて語ろう where OID=2::oid　(雑談part2)
http://pc8.2ch.net/test/read.cgi/db/1136805513/
●関連スレ
2ch検索
http://find.2ch.net/index.php?STR=PostgreSQL
WebProg/PostgreSQL 2テーブル目
http://pc11.2ch.net/test/read.cgi/php/1047317680/

3 ：

テンプレはコピペだがよかったかな?

4 ：

>>前スレ1000
構文解析が済んでいるからって、処理順をすべて無視して良いとは限らないでしょう。
つーか、なぜあなたは自分レス>>前スレ978の不都合さを無視するの?

5 ：

そこは、内部的にそう展開されても問題ないといいたいんだろう

6 ：

みなさん、ま、まさか
case文とか
countとか、sumとかの集約関数さえも知らん奴を相手にしてたのでは
ウンチクを語るならSQLの基本的な仕様を理解してからにして欲しいですな

7 ：

それを抜きにしても(抜いちゃいかんけど)、
言語設計(概念レイヤとでも言うか)と実装レイヤがごっちゃなのよね、あの子。

8 ：

言語仕様あっての実装であって、
そのための字句解析、意味解析なのに、
その仕様である実行順も各句の役割も無視してる
具体例に対してちゃんと検証しようともしてない。まあSQL知らないからしょうがないのかも知れないが、それならそれなりの応対があるだろうに。

9 ：

いちおつ

10 ：

SQL信者の必死さに涙が止まらない
>>4
>>>前スレ1000
>
>構文解析が済んでいるからって、処理順をすべて無視して良いとは限らないでしょう。
処理順を無視してなんかないですよ。where句から処理が始まったとして、それより前に別名を展開する処理を追加しただけですね。
どこをどうみたら、処理順をすべて無視したと感じたのでしょうか。
>つーか、なぜあなたは自分レス>>前スレ978の不都合さを無視するの?
978ってこれ？
978> > 例えば、初心者が何故以下のような文でエラーが起きるか理解できなくなる。
978> > SELECT COUNT(foo) AS cnt FROM hoge WHERE cnt > 2 GROUP BY bar;
978> この例だと WHERE COUNT(foo) > 2 としたところで何の違いもない。
これについてなら、すでに983にあるとおり。
983> 何の違いもなくエラーが出るよってことでいいのかな
WHERE cnt > 2 も WHERE COUNT(foo) > 2 も同じようにエラーになる。それだけ。「不都合」って言ってるけど何が不都合？

11 ：

技術的に可能ならそのまま仕様にすれば良いと思ってるのか？

12 ：

>>10
信者ってw
丁寧に汚い言葉を使わずに、丁寧に返信していたつもりだが、
もう、そう言うようにしかとっていただけないのなら、勝手にしてください。
あ、最後に
>>983> 何の違いもなくエラーが出るよってことでいいのかな
>>WHERE cnt > 2 も WHERE COUNT(foo) > 2 も同じようにエラーになる。それだけ。「不都合」って言ってるけど何が不都合？
そういう意味ね。失礼、取り違えてました。

13 ：

闇雲に否定はしないけど、難しいだろうなと思うのはこういうの。
select
a as b,
b <- selectで別名解決はしないままでよい？
from tableA
where b = 3; <- 別名と、本来のカラム名との区別はどうやってつける？

14 ：

select
rand()*3::integer as id
,val
from
a
where
id < 100
これは？aテーブルにid列があったらどうする？
selectは、物理テーブルと関係のないを作り出したり、
複数列から一つの列を作り出したり出来る。上の人のエイリアスがかぶる場合ってのもそうだし、人間様がどれが欲しいのか理解できるのか？
それとも全部エラーにしちゃうのか？現在の標準仕様ならばなんの不都合もなく実行できるのだが。

15 ：

すまんpostgresだとrandom()だな
select floor(random()*1000)とかと読み替えてくれ

16 ：

もし、前スレ>>990で書いてたようにもとのカラム見ないで
エイリアス優先とかルール作っちゃうと意図したことができなくなるよ
case文で例を、
念のために、aテーブルの構成は
id | subid1 | subid2 | val1 | val2
select
case
when val2 > 100 then subid1
else subid2
end as id
,val1
from
a
when
id > 50
aテーブルのidが50以上の行を抽出して、その行に対してだけcaseの条件文から新しいid列、val1列を導きたいんだけど、
勝手にselect句のcaseが適用されちゃう、どう解決しよう？

17 ：

>>10
＞それより前に別名を展開する処理を追加しただけですね。
正しく動作させるには「前」じゃなくて「スコープの外側」な
from
{
　　�@
　　where
　　{
　　　　�A
　　　　select
　　　　{
　　　　　　�B
　　　　}
　　}
}
「別名を展開」する命令を�@〜�Bのどこに書けばいいか分かるだろ？
Ｃ言語なんかだとどんな馬鹿でも「前」に書けば自動的にスコープ内に入るから
君みたいなプログラミング初心者ほど「前」に書けばいいという固定観念に縛られて
こういうミスをやってしまうんだよ
君はもっと勉強して脳みそを鍛えたらＳＱＬを使いこなせるんじゃないかなあ

18 ：

ちょっと訂正
君はもっと勉強して脳みそを鍛えたらＳＱＬ「も」使いこなせるんじゃないかなあ

19 ：

SQLにスコープという概念が存在するとは思わなかった。

20 ：

>>19
SELECT table1.column1, table2.column2　FROM　table1 INNER JOIN table2 ON　・・・
テーブル名で修飾してるのはスコープの概念そのものなんだが理解できるかい？

21 ：

処理順無視してないとか言って
SELECT COUNT(foo) AS cnt FROM hoge WHERE cnt > 2 GROUP BY bar;
これを
WHERE COUNT(foo) > 2
こんな展開したら明らかに処理順無視してるじゃねーか・・・
WHEREの方が先に動くっていってんだからよう
たまたまWHERE句でcount関数が使えないだけだろ

22 ：

>>19
サブクエリとか分かりやすいスコープ

23 ：

>>21
彼は、そういうのはエラーになればいいだろ、展開して問題ないものだけ動けばいいんだという言い分だと思う。
展開して問題ないものの判断ができない場面があることに気づいてないみたいよ。

24 ：

>>10は非手続き型言語をまったく理解してない
そもそも　列名　AS 別名　とはselect句の出力の属性を宣言しているのであって、プロシージャ（手続き）を宣言しているわけではない
それにも関わらず「それより前に別名を展開する処理を追加しただけですね。」というのはプロシージャを追加したということになり
もはや非手続き型言語ではない
そんな基本的な矛盾に気がつかないようではプログラマとして致命的だ

25 ：

なんだ、楽しみにして帰ってきたのにもう来ないのか？なかなか強烈だったから振り返ってみよう。
いつも過疎で平穏な、DB板のPostgreSQLスレに彼は来た。
「試したところ、エラーになりました。
psql=> select id as ticket_id from tickets where ticket_id < 10;
ERROR: column "ticket_id" does not exist」
どうにもこのエラーが受け入れられないらしい。
思えば初めから他人の話にはほぼ全て否定的であった。
前スレ>>957,968,971,975,978
（そもそもやつがsqlに対して無知だからおかしてる間違いだろ？
字句解析・意味解析の知識はあるか知らんが（ほんとか？評価順の重要さも分かっていないようだが）、
SQLの知識が無いという自覚なしに、誰もsqlを持ち上げたりしてる訳じゃなく仕様を読めって言ってるだけなのに）そう俺は思った。
>SQL信者の必死さに涙が止まらない
あとからこんな言葉が吐かれることになるとは、
この時はまだ思いもしなかった。この言葉は、俺の今後の人生をきっと豊かにしてくれるだろう。
前スレ>>990
>構文解析や意味解析についての、簡単でもいいので基礎知識があれば、
>別名をwhere句で使えるようにするのが特に困難なことではないはずだ、
>というのがすぐにわかるんだけど。
>たぶん構文解析についての基礎知識がないやつが、SQLの仕様書がどうのこうの
>いっているのだろう。
>なぜそういう仕様になっているのかが聞かれているのに、SQLの仕様を読めと
>答えてるのは滑稽すぎる。
最高に恥ずかしい！！！この晩はこれをつまみに一杯やった。
評価順があると、具体例挙げてどう動くか考えろと、言っても無駄だった。
前スレ>>1000
>だーかーら、そのまえにSQLの構文解析と意味解析をしてるでしょうが。
>構文解析　→　意味解析　→　FROM句→WHERE句→SELECT句・・・
>　　　　　　　　　　　　^^
>　　　　　　　　　　　ここで構文解析木を操作して別名を展開すればいいだけ。
>なんでwhere句やselect句の順番にこだわるの。whereやselectの処理に入るまえに別名を展開すればいいだけなのに、なんでこんなことがわからないの。
>なんで結果が変わると思ったの？
とか頓珍漢なこと言っちゃって結局クエリの内容見ないのだ。
（なんで順番にこだわんないの?）よいこのみんなは思ったはずだ。
その後も同じような主張を繰り返した。
（自信満々なのはいいが、人の話をちゃんと聞かないようじゃ何のために質問しに来たんだか…
何かもっと面白い提案でもでるのかと思ってたのに…まぁこんな日も有るか）
大変ワイルドな出来事でした。

26 ：

なっが。
てか、元質問者と同一認定していいのか？

27 ：

気付いて、顔から火吹いて逃げちゃったんだろうか。
正直なところどう感じたのかをお伺いしたい。

28 ：

あれほど自信満々だったら、標準化してるISOなり
pgsql-jpで石井さんに詰め寄るくらいして頂きたかった。

29 ：

ここで復讐を果たす為に専門的知識を必死に習得してるのではなかろうか

30 ：

いや、きっとmysqlスレで同じ事を質問する
「試したらエラーになりました。簡単なことなんですけど、どうしたらできますか？」ってね
もはや何かの陰謀に違いない

31 ：

mysqlだったらあの程度の出鱈目仕様、もう実装してんじゃね？

32 ：

死者に鞭打つ真似はおよしなされ

33 ：

叩くほうがここまで必死なのにはわけがあるんだろ。

34 ：

9.2　32コアまでスケールは凄いな。
index only scanも導入されるし、
カスケードレプリケーション、range型とかも。
もうあれだな。

35 ：

客にバージョン上げようぜっていいやすくなるな

36 ：

やっぱりポスグレは最先端なのですね！
マイエスキューエラーに馬鹿にされなくて済みます

37 ：

ちょっと前までMySQL使ってて、ポスグレちょぼちょぼ使い出したとこやけど、
WITHが便利過ぎてﾜﾛﾀ。
とあるテーブルAから、条件に合うレコード削除して
その内容を「削除済み」用のテーブルBに書いて、
ついでにテーブルCの該当レコードのフラグカラムを書き換え。
これが一文一発で出来て、明示的なトランザクション制御要らず。
気持ち良過ぎやろ。

38 ：

writableCTEはpostgres独自だから意識して使うんだぞ

39 ：

インストーラーで簡単セットアップのWebベースPostgreSQL管理「TeamPostgreSQL」
http://www.moongift.jp/2012/06/20120604-3/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+moongift+%28MOONGIFT+-+%3F%3F%3F%3F%3F%3F%3F%3F%3F%3FIT%3F%3F%3F%3F+-%29&utm_content=LocalHost

40 ：

Windowsの32bit版と64bit版のベンチマーク比較の資料ってどこかにあるんでしょうか？

41 ：

CentOS5.8とPostgreSQL8.4を使っています
logファイルにSQLが出力されるのを抑止し
たいのですが、どのようにすればよいで
しょうか？

42 ：

postgresql.confをいじれ
見てわかんなかったらマニュアルを読め

43 ：

>>41
http://www.postgresql.jp/document/8.4/html/runtime-config-logging.html#RUNTIME-CONFIG-LOGGING-WHEN
log_min_error_statement PANIC
かな

44 ：

いやまあ、log_statement だと思うけど
わざわざ設定しないと出ないはずだが。

45 ：

うん、デフォだと出ないよね

46 ：

alter table テーブル名 add column カラム名
するときに、場所って指定できますか。
たとえばカラム「age」をカラム「name」と「gender」のあいだに追加したいとか。

47 ：

>>46
普通はテーブル作りなおさないとできないんじゃなかったかな。
RDBはもともとカラムの位置を気にしないものだし。

48 ：

SELECT時に順番決めるしね。
*指定したくて気になるならView作ればいいし、
DROPして作りなおすのもありっちゃあり

49 ：

並べ替えが出来るdbもあるのよね
postgresの場合は出来たら便利なのは分かってるけど他に優先度が高いのがあって、手掛ける人がいないってどこかで読んだような

50 ：

これだ
http://wiki.postgresql.org/wiki/Alter_column_position

51 ：

１・２・３

52 ：

順番が気になる人は、ほとんど初心者しかいないから
対応するのもアホくさいと思うがなあ

53 ：

>>52
変更コストがどうかと言う問題はあるけれど。
20列のテーブルで3-5列に処理区分1,処理区分2,処理区分3とあり、
処理区分4だけが21列目。しかも、20列目の入力時刻の後になるというのは
いろいろな意味で好ましいことではない。

54 ：

その考えの先には、
　　:
　予備1　　varchar(100)
　　:
　予備2　　varchar(100)
　　:
があったりして。

55 ：

>>53
すべてのユーザがviewを通してすべてのテーブルを管理しているという訳では
ないからね。やはり列の並び順も少なくとも管理しやすさには大きく関係する。
一般にはね。

56 ：

pg9.1.4のpg_trgmを使った全文検索の速度について
CREATE TABLE documents
(
id serial NOT NULL,
document text,
CONSTRAINT pky PRIMARY KEY (id )
);
CREATE INDEX idx
ON documents
USING gin
(document COLLATE pg_catalog."default" gin_trgm_ops)
documentカラムには、
平均1000文字の英文が100万行格納されています。
上記の状態のテーブルに次のSQLを実行しました。
--「keyword etc」が含まれているかどうか確認
SELECT EXISTS(
SELECT * FROM documents WHERE document_text like E'%keyword etc%'
);
実行した結果は、0.5秒〜300秒を超えてタイムアウトするものまで様々です。
(「keyword etc」の場合10.8秒でした。)
設定ファイルの編集やSQLの改善でもう少し早くすることはできないでしょうか。
ちなみに、実行している間は、実行しているコアのCPU使用率が100%になっています。

57 ：

速度改善とは関係ないけど、EXISTS使うと、1件見つかった時点で切り上げそうな気がする。

58 ：

pg_trgmを使いたいのは複数の単語からなる語句を文章中から検索したいから？
トリグラムを使わずに
CREATE INDEX idx ON documents USING gin(to_tsvector(document));
として、
SELECT EXISTS(
SELECT * FROM documents WHERE document @@ ts_query('keyword & etc') and document like E'%keyword etc%'
);
としたらどうなる？

59 ：

SELECT EXISTS(
SELECT * FROM documents WHERE to_tsvector(document) @@ ts_query('keyword & etc') and document like E'%keyword etc%'
);
のまちがいだった。

60 ：

>57
ありがとうございます。
１件(１行)でもキーワードがあるかどうかを確認したいので、
そのように１件見つかった瞬間に処理を切り上げてもらえるのが助かります。
>58
ご提案ありがとうございます。
なるほど、一度vector検索してから
連語があるか確認するのですね。
一度テストしてから、またお返事させていただきます。

61 ：

1000文字英文100万行くらいなら全然対したことなさそうだけどな
trgrm自体の検索は大体そこそこ早いんだよ
でもインデックスでヒットした後に実テーブル確認しに行ったりするとそこで速度が落ちる。
だからヒット数が多ければ多いほど遅くなるよ。 特にメモリに実テーブルがのっていない場合。
そんな感じじゃない？>>56
そうであれば、差し支えなければそもそもginでヒットする件数をgin_fuzzy_search_limitで抑えちゃうことができるのでそれを検討してみては？ここに書いてあるよ
www.postgresql.jp/document/9.1/html/gin-tips.html

62 ：

56です。返答が遅くなって済みません。
>>58-59
いくつか検証してみましたが、
今より高速になるものもあれば、むしろ速度が落ちるものもありました。
原因としては、
to_tsvector(document) @@ ts_query('keyword & etc')
の段階で該当する行が大量にあった場合、
そこからは、シーケンシャルなlike検索が行われているような気がします。
（ただ、実行計画では、BITMAP HEAP SCANとなっていますので、
　インデックスを使ってなお遅いということなのかも知れません。）
>61
gin_fuzzy_search_limitを1に設定して実行してみました。
確かに実行速度は、早くなったのですが、有るはずの文字列がないと判断されるようになりました。
gin_fuzzy_search_limitを0、または9999999等の十分大きな値に設定すれば、
>56のクエリで[True]が帰ってくるSQLでも、
gin_fuzzy_search_limitの値を小さく（例えば1や10）にすると
[FALSE]が帰ってきます。
where句でヒットした行数を絞って返すという認識なのですが、
（1000件ヒットしても、gin_fuzzy_search_limitが10ならば、10件しか返さない）
間違っておりますでしょうか？

63 ：

そこで設定した数字は正確に有効な行数を表す訳じゃないのよ。
なので小さく設定しすぎると、正しい結果が帰らないこともある。
事情を説明するのが面倒（というかソース追う時間が無くて自分も正確に把握してない）
なので、興味があれば調べてみて。
ということで、速度(と結果)が妥協できるところで、
小さく設定するのがよし。

64 ：

あ、たくさんの行がヒットすると遅いってのは、
　ginインデックスのみからwhere句条件で探す（これは早い。転置なんで当たり前）
　→正しいかどうかヒープ（メモリに納められてる実タプル（もちろん無ければディスク読む））をもう一回条件で調べる
（bitmapの説明は省いた）
て手順だから。プランでrecheckって出てるでしょ？
インデックスっていつも正しい情報が入ってるって限らないのよpgは

65 ：

os: CentOS 5.2 locale=C
postgresql 9.1.2 locale=C, DBの文字コードはUTF-8
接続クライアント
a. WindowsXP上のTeraTerm UTF-8
b. JDBC type4接続 Java文字コードはUTF16BE
2点質問があります。
(1) a.において、psqlが出力するエラーメッセージが文字化けします。
SELECT結果(UTF-8)は問題ありません。
文字化けを解消する、またはメッセージを英語にする方法をご存知であれば教えてください。
(2) b.において、JAVA例外(PSQLException)のメッセージが文字化けします。
ログファイルの文字コードはUTF-8。
SELECT結果(UTF-8)は問題ありません。
こちらも文字化けを解消する、またはメッセージを英語にする方法をご存知であれば教えてください。

66 ：

追記です。
osのタイムゾーンは日本です。
よろしくお願いします。

67 ：

http://www.postgresql.jp/document/current/html/multibyte.html#AEN24155
を参照して文字コードを指定する必要があるのかもしれない。

68 ：

エラーメッセージの話でしょ？
CentOS 5.2 locale=C
て言ってるけど、具体的には何で判断して
どこに設定されてる？LC_ALL？LANGUAGE？LANG？
とりあえずそこら辺を確認して
それからpostgresql 9.1.2 locale=Cていってるけど、
postgresqlはソースから入れたんだよね？
ちゃんとインストールしたpostgresqlが動いてる？
（たまに、インストールしたのにシステムにデフォルトで入ってるpostgresあげてる人とかいるので)
何処に設定したものからCって判断してる？
"実際に動いてるpostgresの"postgresql.confで
lc_messages = 'C'
lc_monetary = 'C'
lc_numeric = 'C'
lc_time = 'C'
になってるかい？
psqlでの
select name, setting from pg_settings where name like 'lc\_%';
の結果
name | setting
-------------+---------
lc_collate | C
lc_ctype | C
lc_messages | C
lc_monetary | C
lc_numeric | C
lc_time | C
みたいにconf(と思っているもの)と一致してるかい？

それを確認した上で、
export LANG=C
してpsqlコマンド使っても化け文字？

69 ：

お二方ありがとうございます。
おかげさまで(1) については解決しました。
原因は、トラブルシュートのテスト用に用意した、意図的に壊した設定ファイルが読まれていました。
正しい設定ファイルに置き換えることで解決しています。
(2) については状況が変わりません。
どうも本体ではなくJDBCドライバの問題のような気がします。

70 ：

Win7でレプリケーションうまくいかないなぁ。

71 ：

pg_dumpでデータ以外のみをエクスポートする方法はないでしょうか？

72 ：

＞データ以外のみ
schemaのことだね？
オプションにあるべ

73 ：

-s

74 ：

ありがほー

75 ：

http://www.postgresql.jp/document/pg823doc/html/datatype-numeric.html
ここに
integer 4バイト
bigint 8バイト
とありますが、これは64bit版でもそうなのでしょうか。

76 ：

>>75
YES. 32/64bitで差はない。

77 ：

>>76
ありがとうございます。
いちおう確認ですけど、x86_64ならintが64bitだから、PostgreSQL 64bit版でもintegerとbigintに性能の差はないと考えていいですよね？

78 ：

CPUのビット数やコンパイラのintの長さと
DBのINTに関係は無いよ、環境に寄らずMDBSが決めたサイズになる。

79 ：

(C)コンパイラのintのサイズにしても、
64bit環境だからって64bitとは限らないし。
というか32bitのままって方が多そう。

80 ：

Postgres9.1.0をソースコンパイルでOSX山ライオンにインストールしようとした。
が、
configure: error: in `/Users/jiro/Downloads/postgresql-9.1.0':
configure: error: C compiler cannot create executables
と文句を言われ途中で止まってしまいます。
対処法をご存知のかたがいましたらご教授願います。

81 ：

あげます。

82 ：

試しに9.1.4ダウンロードしてビルドしてみたけど、問題なかったよ。
Xcodeとコマンドラインツールは入れてるよね？

83 ：

postgresqlでLEFT OUTER JOINをしたいんだけど
片方のテーブルの型がtextでつなげる方の型がinteger
おまけにtextの方が0で頭が埋ってる10桁なんだがどうやるんですか？
教えて下さい偉い人
SELECT * FROM a LEFT OUTER JOIN b ON a.accountcode = to_char(b.id, '0000000000');
これじゃなぜかだめっす

84 ：

どうだめだったの？
a.accountcode：：INT とかでいかない？

85 ：

これでどう？
to_char(b.id, 'FM0000000000');
偉くないので分からないけど、こっちの方が良いかもしれない。
to_char(b.id, 'FM0999999999');

86 ：

不慣れなplpgでトリガ関数いっぱいつくらにゃあかんのですが、
デバッグのいい方法ないですかね？
PgAdmin�Vだと関数のデバッグのみでトリガ関数のデバッグができないようでして

87 ：

RAISE文を使ってprintfデバッグくらいしか思いつかないなぁ。

88 ：

そうですかー。んじゃ今日もトリガと格闘してきます。

89 ：

textsearch_sennaで30個にパーティションに分割したテーブルを
selectすると、必ずpostgresのプロセスごと落ちるんだけど、
何か方法ないですか？
分割した個々のテーブルにならselectしても落ちないんですが、
個々のテーブルをselectするSQLを5つくらいunionでつなげてもやっぱり落ちます...

90 ：

9.2が出たら起こしてくれ

91 ：

PostgreSQL 9.2 RC1 Available for Testing
Posted on 2012-08-27
だいぶ先かな

92 ：

マイエスキューエラーに虐められた時に言い返す方法教えて

93 ：

>>92
比較スレへどうぞ。
MySQL vs PostgreSQL Part2
http://toro.2ch.net/test/read.cgi/db/1123011800/

94 ：

>>92
飼い殺し乙
とか言ってやれ。事実だし。

95 ：

MySQLだと1つのDBに一人のユーザを閉じ込めるっていう隔離ができるんですが、
PostgreSQLでもできますか？
やりかた教えてください＞＜；

96 ：

initdbで作成するとき、場所変えればいい。
複数作れる。同時に起動するときは、それぞれのpostgresql.confで
ポート変えないとならんけどね。

97 ：

superuserにしなければいいんでは？

98 ：

>>96 のようにDBクラスタごと分ける
pg_hba.conf でログインできるDBを制限
スキーマ + ロールでアクセス制限
どれでもお好きに。ちなみに、MySQLのDB ≒ Postgresのスキーマ だと思ったほうがよいかも。

99 ：

idをserialで作ったテーブルがあるんですけど、これをあとからbigserialに変えることはできますか。
alter tableだとsequenceが変わらないような気がします。

100 ：

>>99
自己レスです。
¥d hogehoge_id_seq
すると、なんとシーケンスはbigintで作られているではあーりませんか。
これなら alter table hogehoge alter column id type bigint だけでいけそうです。

101 ：

そもそも serial は、なんでデフォルトで bigserial 相当にならないんですかね？
歴史的な経緯？

102 ：

"int" がデフォルトで32bitみたいなもんじゃないの。64bitはbigintだし。

103 ：

そうころころ替えられないからだろう。
足りなくて困ってる人数ないだろうし。

104 ：

相変わらずintが最速だからじゃない？

105 ：

PostgreSQL 9.2 has been released!
http://www.postgresql.org/

106 ：

>>90
おい、起きろ

107 ：

ん、もうかい？
意外と早いんだな。

108 ：

range 型ｷﾀｺﾚ

109 ：

はじめまして。postgresqlのことをあまり知らない初心者インフラ担当です。
質問があります。
postgresql8.1を使用しているDBサーバがあり、
毎日3:00からVACUUMとDBバックアップを行っています。
通常ではVACUUMに30分くらいかかっていたのですが、
1週間前あたりからVACUUMに6時間くらいかかるようになってしまいました。
今回、原因究明のため商用機を調査することになったんですけど、
VACUUMが急に時間がかかるようになることに心当たりがある方はいるでしょうか？
また、調査する場合はどのあたりから調査していくべきでしょうか。

110 ：

いくら出す？

111 ：

解決しました
さーせんｗ

112 ：

よかったね

113 ：

確かjson使えるよな？待ってたよ〜ん。

114 ：

配列を引数にして、WHERE節で使う関数のWHERE節はどう書きますか？
WHERE serial IN ？$1？

115 ：

WHERE serial = ANY( $1 )
NULLへの対応が必要ならば、別途 調整がいる。

116 ：

あざっす＾＾

117 ：

db_syntax_diffについて、知っている情報あれば、
教えてください！！

118 ：

まずは知っている情報を出してくださいよ。

119 ：

バージョンが9.2になって小文字に変えないとエラーになるコマンドとかあるな・・・。
LANGUAGE 'C'をLANGUAGE 'c'にしないと動かないってとこでハマったわ。'

120 ：

テスト

121 ：

9.2の前はいくつ使ってたの？
select * from pg_language; でCかcの違いじゃないのかなあ。

122 ：

>>121
8.4使ってた。そこでインストール済みの拡張言語見れたのか・・・。

123 ：

20年くらい前から Oracle 使ってて、10年くらい前に全面的にすべてのシステムを PostgreSQL に移行しました。
新規開発も全て PostgreSQL です。現在まで何も問題ありません。
ですが、最近、世界的に MySQL にシェアを奪われ続けており、この先ずっと PostgreSQL を使い続けるべきか、正直、迷っています。
どんなものでしょうか？

124 ：

MySQL自体が存在しなくなる可能性を考えるべき。

125 ：

>>124
なるほど。
よく分かりました。吹っ切れました。
ありがとうございます。

126 ：

やけに納得するのがはえーなｗ

127 ：

MySQLがなくなる可能性もPostgreSQLがなくなる可能性も同じようなもんでしょ
だから>>123は杞憂だよ

128 ：

>>126
心情的には PostgreSQL と心中してもいいかな、くらい思ってるので。

129 ：

今使ってるバージョンがいきなり使えなくなるわけじゃないからな。
無くなってから次考えりゃいい

130 ：

むしろOracleに買われたMySQLのほうが消える可能性高かったりして。MariaDBが一応あるけどねぇ。

131 ：

他人が書いたマニュアルをみながら、作業を進めてると壁にぶつかってしまいました。。。
>createdb -U Postgres -O ユーザ名 DB名
と入力すると、"createdb : コマンドライン引数が多すぎます。(始めは"?O")
と言われるのですが、何がダメなんでしょうか？
バージョンは9.0.4です。
(普段は電気屋さんしてます。)

132 ：

>>131
ユーザ名はアルファベットオンリー？

133 ：

いっつも
$psql -U postgres
#create user ユーザ名;
#create database DB名　owner ユーザ名;
でやってるけど、そんなコマンドあるんだな。

134 ：

>>133
CREATE DATABAS は、 SQL コマンド
createdb は、CREATE DATABASE の shell スクリプトラッパー

135 ：

>>131
はい、そうです。全部小文字。
この前にユーザ作成しました。

136 ：

まず Postgres で蹴られると思うけどな、、、 postgres でやってる？

137 ：

textsearch_sennaで前文検索するとき、
指定する単語は16個までって決まってる？
where　col %% '単語１ or 単語2 or 単語3 or .... or 単語16'
の検索結果と
where　col %% '単語１ or 単語2 or 単語3 or .... or 単語16 or 単語17'
や
where　col %% '単語１ or 単語2 or 単語3 or .... or 単語16 -単語17'
などの結果が全部同じなんだけど、
postgresの仕様？
sennaの仕様？
textsearch_sennaの仕様？

138 ：

>>136
あ、それはこのスレに書き込む時、携帯の自動処理で大文字になってしまったのです。。。

139 ：

コマンドライン引数が云々、はシェルが出してるんかな
環境はWindows?

140 ：

>>139
「>」ってなってるからWindowsっしょ

141 ：

>>137
or検索だからなのでは・・・？
あと、postgresの全文検索はインデックスが壊れる事がちょくちょくあったような。
そもそもsenna使ってる時点でノイズは結構出るから、あまり気にしなくていいのでは？

142 ：

みなさん、PostgreSQL のメジャーバージョンアップって
どうしてます？
うちの会社は基本的に２４時間３６５日営業しているので、
ネット（システム）を停止できないです。
事情があれば、顧客に事前に通知して１日とか一斉休業するんですけど、
やっぱ、なかなかバージョンアップだけではそこまでできません。
セキュリティホールとか殆ど無いですからね、PostgreSQL…

143 ：

>>142
そんな装備で大丈夫か？

144 ：

psqlで変数って使えないの？
$name = 'foobar';
select * from table where name = $name;
とかしたい。

145 ：

>>144
若干使いづらいところはあるが、 \set と :varname 。
http://www.postgresql.jp/document/9.2/html/app-psql.html#APP-PSQL-VARIABLES

146 ：

>>145
さんくす

147 ：

>>143
すいません、「装備」とは？

148 ：

>>142
どういうシステムか知らないけど、普通に動いて特に困らないならバージョンアップはしなくていいんじゃない。
さすがに未だ7使ってるなら計画練ってアップデートしたほうがいいと思うけど。

149 ：

質問者とは別人だけど興味深い質問なのでおれも知りたい。
>>148
それはうまい解決方法がない、ということでいいのかな。

150 ：

>>149
そういえばこの質問は止めたらマズいシステムで止めずにアップデートするには？だったか。
Slonyとpgpool使えばノンストップでバージョンUPいけるらしいけど、テーブル増えるから俺は使いたくないなー。
１日止めるような要件の時に一緒にやっちゃうのがいいんじゃない。

151 ：

化学屋やってます。 PostgreSQL 8.4 です。
時々、大量のレコードを更新や挿入するのですが、
とても時間がかかるため、
BEGIN; DROP TABLE して、
COPY table FROM stdin;
....
\. COMMIT;
のようにしようと考えています。
この処理の実行中、tableにアクセスされても問題ないのでしょうか？
あるいは BEGIN; の直後に LOCK table; は必要なのでしょうか？
レベルの低い質問ですみません。

152 ：

すみません、あまりにもレベルの低い質問で。その心情を吐露すれば、つまり
レコードレベルのロックであれば、テーブルそのものはなくなるわけではないので
普段は気にしないでSQLを書いていたのですが、今回初めて テーブルそのものを
DROP するため、不安になっているのです。トランザクションってのはつまり、
ROLLBACK さえすれば DROP そのものも無かったことにできるものだろうとは思うし、
DROP してしまう table をLOCK してもしょうがないだろうし・・・。混乱中です。

153 ：

>>152
PostgresqlだとDROP TABLEやTRUNCATEやCOPYコマンドにもトランザクション制御ができるのはそのとおり。
DROP TABLEやTRUNCATEを実行すると、内部でACCESS EXCLUSIVE LOCKがかけられて、処理中は自分以外が
対象のテーブルにアクセスできなくなる。
http://www.postgresql.jp/document/8.4/html/explicit-locking.html#LOCKING-TABLES

154 ：

>>153
ありがとう御座います。
自動的にACCESS EXCLUSIVE LOCKがかけられるのですね。すっきりしました。
ユーザー側からはリードオンリーの巨大なテーブルだったので
挿入や更新の度に >>152 を行おうと思います。

155 ：

もっと基本的な部分を見直すと１０倍ぐらいは速くなるとかいうパターンじゃないかねぇ。。。

156 ：

>>155
何千件ものレコードを 更新または挿入するんです・・・。
インデックスをDROPしてからINSERT or UPDATE して、
またインデックスをCREATE するというのもやってみたんですが多勢に無勢でして。
状況としては管理者のみが編集できるマスターテーブルの更新です。
もちろん何千件といっても、実際の変更箇所は全レコードの数％なんですが、
変化したかどうかサーバーに問い合わせるのも時間かかるし、
そのマスターテーブルが Excel という仕様なので、>>151に考えが至ったのです。

157 ：

業務アプリのバッチ系なんかだと、毎日何万件ものデータを
（複数の表に対してインサートやアップデートだけじゃなく計算したりして）
処理するというのを分のオーダーでやってるんですけど。。。
まともなプロに見せたら、１時間ぐらいで１０倍速くしてくれると思うよ。

158 ：

UPDATEにINDEXが使われてなくて遅いだけだったりして

159 ：

たったの数千件なのか。普通のトランザクションかけるだけでいいんじゃないの。

160 ：

>>157 >>159
いや、挿入更新処理を 遅くとも2〜3秒以内で終わらせたいのです。
>>158
そうなんです。状況によってそれもありえるのが厄介で・・・。

161 ：

>>160
>いや、挿入更新処理を 遅くとも2〜3秒以内で終わらせたいのです
じゃ今、何秒かかってるの？

162 ：

>>161
ひどいときだと20〜30秒くらいかかってました。
COPY で書き換えた所、1秒くらいで終わりました。

163 ：

たぶん更新系のSQLを数千回発行してるから、毎回ディスクをflushしに行って遅くなってるんだと思う。
たとえDELETEとINSERTを使って20〜30秒かかっても、その間も他のユーザーは更新前のテーブルを参照できるんだから、
数秒のテーブルロックをかけるよりもシステムのロックがなくていい気がするけど、
COPY文を使って1秒テーブルがロックする程度のことを許容できるなら、そのやり方も早くて簡単でいいと思う。

164 ：

>>160
それがわかってるならINDEXが使われるようにしたらいいだけでは？

165 ：

>>163
おっしゃるとおりなんだと思います。今はまだマスターテーブルの管理者が一人だからいいですが、
そのうち別のキャンパスにもおきたい、とかなってくると話がややこしくなってきそうなので
そのときに備えて今から前任者の「Excelでマスターを編集」という状況から脱したいと思います。
ただ、やっぱ便利なんだな・・・いろいろと。
>>164
更新挿入の時にこちら（管理者）がWHERE句で参照する部分のINDEXはもちろん残しています。
ただ、他にも１０以上のINDEXがはってあって、それの更新に時間がかかっているのかな？と
おもい削除してみたりしましたが、たいして変わらなかったんです。
今にして思うと COPY文でインデックスのCREATEもふくめて１秒で完了しているということは
INDEXの更新自体は殆ど関係無かったのでしょうかね。

166 ：

UPDATEして、できなければ INSERT するという書き方は
なんとかすっきりできないものなのでしょうかねぇ。
MERGEをずっと心待ちにしているのだけど。
>>165
それにしてもインデックスの作成が早すぎて不思議な気分です。
ちょっと気味が悪いくらいです。と思って見直したら幾つかのインデックスを張り忘れていたｗ
それでもトータルで２〜３秒・・・やっぱ不思議だ・・・。

167 ：

キャンパスって、、、大学かよ。
まさかパソコン詳しい先生が一人も居ない大学なの？
よくわからんが、多分統計情報が古いんだろ。
オラクルみたいなhintを埋め込むことができないのは不便だが、
例えば1000行INSした時点でanalyzeするとかしてみれば改善されるんじゃないか？

168 ：

雰囲気からアップデートの要否判定とかしてないよね。
それならtruncate->copyでいいと思うわ。
何もdropする必要はないかと。

169 ：

ひょっとして、ＳＱＬをクライアントから発行してるんではないだろうか。
INSERT
if not inserted then UPDATE
INSERT
if not inserted then UPDATE
INSERT
if not inserted then UPDATE
...
みたいな感じでクライアントから数千行INSERT/UPDATEしようとしているんなら遅くて当然だよな。

170 ：

>>167
そう。大学系。試薬系のデータベスなんですけど、（あまりいうと特定されるのでよしときますが）
前任者の残していったシステムで、この板のみんなが見たらあんまりなテーブル設計で腰を抜かすと思いますよ？
プライマリ以外にインデックスが付いていないというのもビックリ。
素人の自分ですらガンガン高速化できて楽しめましたよ？
式インデックスをつけたときは本気で感動されました。
>>168
明日、早速 truncate で試してみます。
>>169
まさにそんな感じでぶらうざ経由でphpから更新する使い方ですた。
あまりにも遅いので業を煮やしてこないだターミナル経由でアップするように作り変えたという次第です。

171 ：

>>167
8.4って統計情報の更新、自動じゃないんでしたっけ？
勝手に最適化されているんだと思ってました。
調べてみます、ヒントをありがとうございます。

172 ：

>>170
PK以外でINDEX付けないのは良くある。
というか、たかが数千行程度ならINDEX要らん。
INDEX付けると、それが効いてるSQLが速くなって感動するかもしれんが、
INSERTやUPDATEが遅くなって、全体でみると却って遅くなってる場合がある。

173 ：

>>172
なるほど！勉強になります。案外とそういう配慮があったりして・・・。

174 ：

あと、テーブルが全部メモリに乗っかるようにチューニングした？
規模的に余裕だと思う。

175 ：

式インデックス付けた？？？
そりゃINS/UPDが遅くなるわな。。。

176 ：

開発環境で使っているpostgresqlのデータベースファイルを、ローカルのディスクから
NFSマウントしたディレクトリに移動しようとしています。
こんなことして大丈夫でしょうか。本番環境ではないので、負荷は心配しなくていいですが、
DBに不整合が発生するようなことはたとえ開発環境といえど避けたいです。

177 ：

>>166
>UPDATEして、できなければ INSERT するという書き方は
>なんとかすっきりできないものなのでしょうかねぇ。
>MERGEをずっと心待ちにしているのだけど。
9.1からこういうことができるようになったらしい。へえー
http://lets.postgresql.jp/documents/technical/9.1/1#syntax
> 例2 : MERGE 文はまだサポートされていませんが、UPDATE できなかったキーを持つ行のみ後から INSERT を行うと、
> 他DBの MERGE や REPLACE 文と同等の機能を実現できます。

178 ：

>>176
良いよ。
バックアップ＆リストアなんて基本的にファイルコピーだし。

179 ：

MERGEってのはUPDATEとINSERTを一つにして速くするって目的でできたものじゃないんだけど。
結果的に呼出しが１回になったからその分速くなっただけで。

180 ：

>>176
NFSのsyncオプションを有効すれば不整合は起きないかもしれないけど、
更新がとても遅くなるかもしれない。

181 ：

ユニークキーについて相談です。
こういうテーブルがあったとして、
create table example (
id serial primary key,
name varchar(255) not null,
created_at datetime not null default current_time
);
ここで、名前と日付（nameとdate(created_at)）の組み合わせが一意になるように
ユニークキーを作ることはできますか。
dateカラムを作るのが簡単ではありますが、それを作らずに済む方法があれば教えてください。

182 ：

これで作ったユニークキーって、何に使うつもり？

183 ：

ふつうに
CREATE UNIQUE INDEX X ON example (name,created_at);
では駄目なのかい？

184 ：

式インデックスを使って、
CREATE UNIQUE INDEX X ON example (name,date(created_at));
とすればできる。

185 ：

名前と日付の組み合わせだけで、本当に一意になる？

186 ：

そりゃdatetimeの精度でも同じ時刻になる可能性は0ではない。

187 ：

>>184
uniqueにするだけだから、date()する必要ないよ。

188 ：

「時刻」ではなく、同じ「日付」に同じ名前の人がいないことを保証したいんだと思うよ。
式インデックスでいいんじゃないかな。

189 ：

同じ日に同姓同名の人は登録できないって意味とは考えにくいな。
むしろ同姓同名の人が登録した時に、それぞれを識別しようとして日付を足しただけに見える。
（なんで連番使わないんだってことになるけど、多分知らないんだろう）。

190 ：

>>188
だね

191 ：

>>189
人名かどうかなんてかいてないし、実際はユニークな型番かもしれない
まぁあれこれ推測して楽しむのを止めはしないけど

192 ：

>>184
>CREATE UNIQUE INDEX X ON example (name,date(created_at));
おおっ、すばらしい！ありがとうございます。
どうせできないだろうと思ってたのに、できるんですね。きいてみるもんです。
>>188
>「時刻」ではなく、同じ「日付」に同じ名前の人がいないことを保証したいんだと思うよ。
はい、その通りです。同じ名前が1日に高々1件しか登録されないことを保証したかったので。

193 ：

psqlコマンドを実行する時に、なぜかperlがらみのエラーがstderrに出てました。
psqlコマンドが内部でperlを呼び出すことはありますか。
なおpsqlコマンドを使って copy (select ...) to stdout as csv を実行しています。

194 ：

PAGER何にしてる？

195 ：

create_atを日付だけにすれば良いじゃないか。
なんでdate型じゃなくてdatetime型使うのよ？

196 ：

そりゃ欲しいからだろ。
dateとtimeに分けておけばよかったかもしれないけどね。

197 ：

いやいや、date型が別にあるなんて知らないって奴も居るかもしれんよ。
ここでunique indexの作り方聞いてくるぐらいだしな。

198 ：

>>197
>>181
> dateカラムを作るのが簡単ではありますが

199 ：

>>198
dateカラムってのはdate型という意味？

200 ：

psqlで、read-onlyモードっつーものはないでしょうか。viのviewモードのようなやつ。
誤ってデータを改変してしまうのを、万が一でも防ぐために。

201 ：

>>200
psql で最初に SET default_transaction_read_only=on; するとか？

202 ：

selectだけ実行してる分には改変されることはないはずだが。

203 ：

んーまーストアドとか

204 ：

>>200
read-onlyなユーザを作る

205 ：

>>202
serialが上がっていくのが気に食わない人もいるかもしれない

206 ：

最近出たMac miniにCentOS+PostgreSQLをインストールしてpgbenchしてみたんだけど、すごく遅い。
何がいけないのだろうか？
Mac mini: Core i7 2.3GHz クアッドコア
HDD: 5,400rpm 1TB
CentOS release 6.3 (Final)
Linux localhost 2.6.32-279.el6.x86_64 #1 SMP Fri Jun 22 12:19:21 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
PostgreSQL: 8.4.13
$ pgbench -i test
$ pgbench -c 10 -t 1000 test
starting vacuum...end.
transaction type: TPC-B (sort of)
scaling factor: 1
query mode: simple
number of clients: 10
number of transactions per client: 1000
number of transactions actually processed: 10000/10000
tps = 84.380053 (including connections establishing)
tps = 84.399439 (excluding connections establishing)

207 ：

diskが遅いんでは？

208 ：

5400rpmってことは、90rps(秒)なんだから、commitする度に
律儀にdiskに書き込んでるとするならば、84.4tpsってのは妥当な線なんでは？

209 ：

TABLEサイズ＋INDEXサイズがshared_buffersの設定値を超えている状態で、
あまりアクセスされないデータを検索するSQLでexplain analyzeすると
INDEX SCANになってても初回のみ30秒ぐらいかかることがあります。
2回目以降は1秒以内に帰ってきます。これを最初から早くすることは可能ですか？
あるいはINDEXだけならshared_buffersに収まるサイズなので、INDEXだけでも
常時キャッシュされるようにすれば、早くなるのかな？とも思ったのですが、
考え方はあってますか？また、そのようなことは可能でしょうか。
postgresql9.1です。

210 ：

>>209
あってると思うよ。
データを空読みすればいい。

211 ：

>>210
データを空読みってcount(*)を取れってことでしょうか？
それだとテーブルデータがキャッシュされて、他のINDEXが
キャッシュから押し出されたりはしないのでしょうか？

212 ：

>>211
INDEXのサイズは何100MB〜何TBぐらい？
数〜数十MB単位じゃないよね。

213 ：

>>212
全テーブルのINDEXを合わせると3GBぐらいです。
メモリは16GB積んでてshared_buffersは4GBです。

214 ：

buffer増やせば？

215 ：

>>214
全テーブル＋INDEXがのるだけのshared_buffersが確保できるだけの
メモリを積むことができるのなら最初から質問なんかしていません。
INDEXのみをキャッシュする方法はないということでしょうか。

216 ：

たぶんない。9.2でやっと INDEX ONLY SCAN が追加された。

217 ：

postgreSQLの統計情報ビューの使いどころがわからないです。
ご存知であれば教えてください。

218 ：

毎日眺めてれば半年もすればわかるようになる。
近道はないよ。

219 ：

>>207
HDDは速くはないけど、それほど遅いとも思えないんです。
# bonnie++ -d /var/lib/pgsql/data/ -n 256:1024:1024:16 -u root
Version 1.96 ------Sequential Output------ --Sequential Input- --Random-
Concurrency 1 -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP /sec %CP
localhost 7472M 970 97 63074 5 29105 2 4534 90 93805 4 251.2 4
Latency 8409us 395ms 1243ms 34163us 79412us 336ms
Version 1.96 ------Sequential Create------ --------Random Create--------
localhost -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
files:max:min /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP /sec %CP
256:1024:1024/16 10872 21 119910 54 40953 45 11077 22 2487 1 1091 1
Latency 1873ms 492ms 1037ms 1903ms 7695ms 10302ms
Macbook(Core2Duo 2.26GHz)上の仮想環境にインストールしたCentOSだと、tpsは500〜600程度、
さくらのVPS（安いやつ）で試しても、同じくtpsは500〜600程度だったので、ひょっとしたら1000超えるかもと
思っていたので、遅すぎて途方に暮れてます。
HDD環境では、どの程度のtpsが普通なんでしょうか。

220 ：

ちなみにSelect Onlyだと結構速いです。
$ pgbench -S -c 100 -t 10000 test
starting vacuum...end.
transaction type: SELECT only
scaling factor: 1
query mode: simple
number of clients: 100
number of transactions per client: 10000
number of transactions actually processed: 1000000/1000000
tps = 33454.043328 (including connections establishing)
tps = 33727.065343 (excluding connections establishing)

221 ：

>>219-220
>>208

222 ：

>>221
えっと、それは
while (true) {
　　fputs("abc", fp);
　　fflush(stdout);
}
が5400rpmのHDDだと、どうあがいても90回程度しかループできないということですか？

223 ：

15000rpmのHDDに変えてみたらわかるじゃん。

224 ：

RAM disk で試しても、HDD ネックかどうか位は分かるんじゃね。

225 ：

>>222
HDDのキャッシュが無効化されていてかつ、fflushじゃなくてfsyncならそうなるかも

226 ：

ついでにここも読んどけ。
ttp://www.postgresql.jp/document/9.1/html/runtime-config-wal.html

227 ：

みなさま、いろいろな情報ありがとうございました。
今まで、なんとなくなんですが、HDD以外のハードのスペックが上がれば、それなりに更新性能も
上がるんだと思ってたんですが、HDDの性能で頭打ちになるんですね。
5,400rpm程度のHDDだと、最高でも5,400tpmしか出ないということか・・・。

228 ：

SSDでやってみな

229 ：

DROP DATABASEでは現在接続中のDBを削除できないので
dropdbコマンドを使って削除するとの事なんですが、
ではdropdbコマンドはどうやってDBを削除してるんでしょうか？
内部の動きが知りたいです

230 ：

>>229
postgresかtemplate1

231 ：

>>230
ではテンプレートデータベースも含めた全てのDBを削除することは出来ないってことですかね

232 ：

ディレクトリごと消せばいいのでは

233 ：

PostgreSQL8までは以下の正規表現が使用できましたが、PostgreSQL9.2からエラーになってしまいます。
　select cast( regexp_replace('123', '(.)(.)(.)*', '\\2') as int) as count
ERROR: 型integerの入力構文が無効です: "\2"
SQLステート:22P02
\\を\にすることでエラーを回避できました。
select cast( regexp_replace('123', '(.)(.)(.)*', '\2') as int) as count
プログラムでこのSQLを動かしているのですが、サーバの設定を変更しないでPostgreSQL8、PostgreSQL9.2両方に対応するには、
if文でいちいち分岐しなければならないのでしょうか？

234 ：

>>233
http://www.postgresql.jp/document/9.2/html/sql-syntax-lexical.html#SQL-SYNTAX-STRINGS-ESCAPE

235 ：

>>227
いや、、、大抵はカーネルキャッシュ、デバイスのキャッシュがそこをひろうから。。。

236 ：

書き込みをキャッシュしてしまうとcommitの意味がなくなるだろ。。。
バッテリー内蔵のRAIDカード使ってるとかなら別だが。

237 ：

書き込みはOSが受け持つんじゃないのかな？

238 ：

>>236
何言ってんだハゲ

239 ：

>>237
>>226

240 ：

>>236
>書き込みをキャッシュしてしまうとcommitの意味がなくなるだろ。。。
commit ってディスクにデータが書かれることを意味しないぞ。

241 ：

そういう使い方もあるわな。
普通はディスクにLOGが書き込まれたということが重要なんだが、
同期レプリケーションなんかだとレプリカにデータ送っただけで良しとするのもありだな。
そもそもデータが壊れても気にしないよ、って使い方もあるだろしな。
どっちが普通なのかは議論になるかも知れないな。

242 ：

>>241
話がずれてる

243 ：

ジャーナルファイルシステムを信用しようぜ

244 ：

デッドロックについて質問。PostgreSQL 9.1。
トランザクションAが、あるテーブルtable1にinsertします (updateではない)。
別のトランザクションBが、table2をupdateします。
そしてtable1とtable2は、どちらもcustomersテーブルへの外部参照をもっています。
このとき、以下のような「customersテーブルにshared lockがかかってデッドロックになった」というエラーが出るんですが、どういうことでしょうか。
DETAIL: Process 30798 waits for ShareLock on transaction 1779489; blocked by process 30802.
Process 30802 waits for ShareLock on transaction 1779490; blocked by process 30798.
HINT: See server log for query details.
CONTEXT: SQL statement "SELECT 1 FROM ONLY "public"."customers" x WHERE "id" OPERATOR(pg_catalog.=) $1 FOR SHARE OF x"
疑問点：
・トランザクションAでもBでもcustomersテーブルは更新されないのに、なぜshared lockが必要なのか？
・shared lockが必要だとして、（exclusive lockではない）shared lockだけでなぜデットロックが発生するのか？
・どう解決すればいいのか？あるいはどう深く調べればいいのか？
よろしくお願いします。

245 ：

よくわかんないけど、ヒントくれてるんだから、その通りにしたら？
> HINT: See server log for query details.

246 ：

>>245
サーバのログには、実行中のSQLが出ているだけでした。
つまり insert into table1 .... と update table2 set .... が表示されているだけで、
ほかに手がかりは載ってなかったので。

247 ：

外部キーと共有ロックとデッドロック
http://itpro.nikkeibp.co.jp/article/COLUMN/20050904/220557/?ST=oss&P=3

248 ：

>244
　shared lock がかからなかった場合、どうなるか考えてみよう。
　table1 へ insert しているデータは、当然 customers テーブルを外部参照している関係上、
customers テーブル上に「レコードがある」ことが必要。
　仮に customers テーブルにロックをしない場合、
table1 insert → customers delete → table1 commit
って順序で処理が起きたら、table1 に、「対応する customers レコードがない」データが作ら
れてしまう可能性があるだろ？
　従って table1 への insert トランザクションが完了するまでは、customers テーブルを更新
されてはまずい。故に排他ロックがかかる。

249 ：

長すぎて読む気がしない。。。

250 ：

>>248
> 仮に customers テーブルにロックをしない場合、
テーブルロックする必要はないですよね。行ロックだけでいいはず。
> customers テーブルを更新されてはまずい。
テーブルの更新はいいのでは？該当行の更新がまずいだけで。
> 故に排他ロックがかかる。
あれ、shared lockって排他ロックのことなんでしょうか。
読み取り用のロックではないのですか？

251 ：

>>247
ありがとうございます。そこを読む限り、排他ロックではなくshared lockだからデッドロックは起こらないはずなんですよね。
以下引用
> PostgreSQL 8.1では共有ロックによって問題を解決
>
> 　このような外部キーの問題は、共有行ロックを導入することによって解決できる。
> 共有ロックでは、共有ロックを発行するトランザクションはお互いに相手をブロックしないため、
> 外部キーをめぐってトランザクションがお互いにブロックして並列実行性を損なうこともないし、
> 外部キーが原因のデッドロックをひきおこす心配もなくなる。
結局、原因はわからずじまいか。

252 ：

>>244
table1かtable2にcustomersを更新or削除するトリガーでも張ってるんじゃない？

253 ：

Postgresqlの入門書は今読むならどれがいいでしょうか。

254 ：

ttp://www.postgresql.jp/document/9.2/html/

255 ：

新しいシーラカンス本でないねぇ。

256 ：

>>244
ログにShareLockと書かれているのはデッドロック時のお決まりの文言。
実際に何のロックがかかっているかはpg_locks見ないと分からないよ

257 ：

OS X上で使用していますが、MySQLのSequel Proの様にGUI上でCSVのエクスポートとインポートができるアプリってありますでしょうか。

258 ：

phppgadmin

259 ：

pgAdmin

260 ：

素のpgAdminではインポートはコマンドベースでしかできない

261 ：

Navicat

262 ：

話題は？

263 ：

9.2どうよ？

264 ：

Windows7 x64, PostgreSQL 9.2.1.1(x64)
でApache,PHP等と連携したデータベース構築を試みています。
UTF-8エンコードとしてdb作成し、そこにテーブルを作り
INSERT文を複数列作成したUTF-8文字コードのtextファイルを \i コマンドで読み込ませると
以下の2種類のエラー羅列で埋まります。。
character with byte sequense 0xef 0xbb in encoding "SJIS" has no equivalent in encoding "UTF8"
invalid byte sequence for encoding "SJIS": 0x82 0x30
このテキストファイルをSJISに無理やり変換すれば問題無くINSERTされますし(当然化ける文字も有り)、
エラーを吐く行などをペーストしてコマンドプロンプトから直接実行してもうまく行きます(ただし表示させると一部化け有り)
UTF-8テキストのまま実行するにはどうしたらよろしいでしょうか・・・助言のほどよろしくお願いします

265 ：

コマンドプロンプトの文字コードをUTF8にすればいい。chcp 65001
そもそもコマンドプロンプトじゃなくてGUIツールを使いなさい。

266 ：

レスありがとうございます
取り敢えずCMDの文字コードはchcpで変更してみましたが結果は同じでした
まあ、これは入出力・表示文字コードの問題なのでファイル入出力とは関係ないとは思ってましたが(合ってるかな？？
GUIツール・・・ということで最初に思い立ったのはpgAdminIIIについてるSQLクエリ実行ツール？でやってみたら上手く行きました！！
今までTeraTermでLinuxのDBサーバにアクセスしてCUIで弄ってたので目から鱗です。
他にもGUIツールってあるんでしょうか。
が、、しかしあまり原因がはっきり解ってない上に
pgAdminIII が多機能過ぎてついて行けてない自分がいます。。orz...

267 ：

コマンドプロンプトの文字コードだけ変えてもフォントの変更もしないと
UTF8の日本語はまともに扱えなかったはず。
DBもファイルもプログラムもCUIでの操作も全部同じ文字コードで扱わないと駄目。
>他にもGUIツールってあるんでしょうか。
ちょっと上にも書いてるがフリーでメジャーなのはpgAdminIIIとphpPgAdmin、
商用でもよければNavicatが便利。ただしNavicat Premiumじゃなければ機能的に微妙

268 ：

>>266
psqlの\iはlinuxで言えばcat ファイル | psql -cと同じこと
クライアントの文字コードに引きずられる

269 ：

>>266
psqlでログインした後、\iの前に
set client_encoding to 'utf-8';
すればINSERTスクリプトは通るんでは。
その後SELECTしたら文字化けしそうだけど。

270 ：

話題は？

271 ：

すいません、今考え中

272 ：

テーブルの最後の50行だけ頂戴って時はどうしますか？

273 ：

order 条件逆にして、top 50
順序が重要なら、その結果を元の orderでソート

274 ：

>>273
あざっす＾＾
reverseのreverseってパフォーマンス的にどうなんすかね
�@PostgreSQLに両方やらせる
�APostgreSQLに最初のreverseを、クライアントプログラムで更にreverse
どっちが速いですかね？
※接続は１つだけの個人専用システム

275 ：

今時 50件程度ならパフォーマンス云々はあまり気にしなくていいんじゃね。

276 ：

あざっす＾＾
�@でいきます
ひょっとしたらよく判らん最適化されるかもしれないし

277 ：

話題は？

278 ：

すんません、質問です。
testテーブルはこんな感じのとき、
key ver value
--- --- -----
CPM 1.4 1000
CPM 1.2 500
OS2 5.0 2000
OS2 4.0 1600
WIN 3.1 50
WIN 95 200
WIN 98 2
--- --- -----
CREATE UNIQUE INDEX test_pkey ON test USING btree (key, ver);

以下の実行結果のように key ごとに、それらの ver が最大の value を選択するSQLを検討中です。
実行結果
key ver value
--- --- -----
CPM 1.4 1000
OS2 5.0 2000
WIN 98 2
--- --- -----
いまのところ２つ考えてみましたが、もっと速いSQLってありますか？
SQL1:Total runtime: 6.492 ms
SELECT key, ver, value FROM (SELECT key, ver, value, rank() OVER (PARTITION BY key ORDER BY ver DESC) AS rnk FROM test) AS temp WHERE rnk=1;
SQL2:Total runtime: 3.539 ms
SELECT * FROM test AS temp WHERE NOT EXISTS ( SELECT * FROM test WHERE key=temp.key AND ver>temp.ver );
ちなみに、テーブルは key が20種類くらい、keyごとにvalueが20個ぐらいです。

279 ：

SQLの入門書を最後まで勉強してみると良いよ。
特別PostgreSQL用でなくても大丈夫だよ。

280 ：

ちょい古いが、9.2.2リリース(2012-12-06)
http://www.postgresql.org/docs/9.2/static/release-9-2-2.html

281 ：

>>278
SQL質疑応答スレ 13問目
http://toro.2ch.net/test/read.cgi/db/1343899481/4
これと比較してみたらどうでしょ

282 ：

知ってりゃ凄く簡単なことでも、知らない奴は凄く複雑にするんだな。。。

283 ：

>>281
同じ条件で試してみました。
Total runtime: 3.204 ms
おぉ、僅差かもしれないけど、これが一番速いですね。ありがとう。
>>279
考えてみたらSQLの本なんて１度も読んだことなかった。
自分には一読が向いているような気がしてきたよ。どうもです。
>>282
まさに、それだね。

284 ：

質問です。教えてください！！！
PostgreSQLの同期レプリケーションで、マスタサーバがダウンした時に、
実行されているトランザクションがスレーブでコミットされたか、
アボートされたかを確認する方法ってありますか？
ユーザにはコミット応答がかえって来ませんでしたが、スレーブを昇格させて
新マスタにしたところ、コミットされデータが更新されている事象が発生しています。。。
よろしくお願います。

285 ：

同期取れてるんだから、コミット済みに決まってるだろ。

286 ：

bit varying に対する set_bit とか get_bit って無いんですか？
PostgreSQL 8.4 です。

287 ：

overlayとsubstringでやるとかかなあ、使ったこと無いが

288 ：

そんなところですかねぇ・・・。
bytea だと簡単なのに、そうすると & とか | が使えない・・・。

289 ：

>>280
英語の質問です
〉Fix the syslogger process to not fail when log_rotation_age exceeds 2^31 milliseconds (about 25 days)
not to じゃないの？

290 ：

timestamp without time zone の【最遠の未来】を返す定数ってありましたっけ？

291 ：

その型で使えるかどうかは知らんけど 'infinity' かな。
http://www.sraoss.co.jp/PostgreSQL/Manual/document/9.2/html/datatype-datetime.html#AEN5786

292 ：

>>291
まさにそれでした。使えることを確認しました。ありがとうございます。
未定義をnull にしたくなかったので助かります。

293 ：

物のついでに INT4 の最大値をあらわすものをググっているがこっちは発見できないな。
使い道は無さそうだから別に無くてもかまわないが。

294 ：

>>292
だが、その方法を使うと、実際の日付がその値を超えたところで矛盾するから
気をつけたほうがいいな。だいたい2943世紀ごろだが。

295 ：

のちの2943世紀問題である

296 ：

どこに質問したらよいかわからなかったのでここに失礼します。
PostgreSQLのテーブル単位のレプリケートが必要になっていろいろと調べているところですが、
slony-Iは、多対一の非同期レプリケート（のようなこと）は設定で出来るか知っている方おります？
具体的には複数のサーバーにレプリケートしたいテーブルがあって、
それらはサーバー同士の間でもユニークなレコードを持っていて、
これらを1つのサーバーに UNION みたいに集めたいのです。
難しいようでしたら自作しようと考えているのですが
slonyで可能であれば楽できるなと思っているところです。

297 ：

>>289
"fix * to not"でググると、良くある言い回しみたいだよ。

298 ：

てか、not fail when 〜に修正したのでそもそもおかしくない

299 ：

sysloggerプロセスが25日有効だったlogをrotationしようとするときに、今までは死んでたのを修正したってことじゃないの？

300 ：

じゃなくて、rotationしそこなうのを修正したのか

301 ：

Ubuntu12でPostgreSQL使ってるけど、apt-get installするより自前でコンパイルしたほうが速いバイナリができるとか、そういうびっくりなことってないかな。
だれか検証したひとがいたら教えて。

302 ：

自前でコンパイルする方が速い可能性はある。
コンパイル時に、PCに載ってるCPUに応じたコードを生成させたりできるから。

303 ：

>>302
速くなる可能性があるのは分かるんですが、実際速くなった人はいるかなと思って。
CentOSだとrpmパッケージがi386でコンパイルしてるから、いまどきのCPUならコンパイルし直したほうが速くなるけど
Ubuntuはdebパッケージがi686でコンパイルされてるようだから、変わらないかもしれない。
でもPostgreSQLのコンパイルはめんどくさいので、だれか試した人がいたら教えてください。

304 ：

>>303
めんどくさいって、ふつーに configure;make;make install だけだろ

305 ：

まぁGCC入れたりライブラリ入れたりしなくちゃならんから、面倒くさいというのも理解できる。

306 ：

9.3出たら起こしてくれ

307 ：

　　●●●ケネディ大統領は何故、死なねばならなかったのか？●●●
　　http://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1226114724/53
　　￥￥￥￥￥￥￥『万有サロン』書き込み大賞・総額100万円￥￥￥￥￥￥￥￥￥￥￥￥
　　この掲示板に優秀な書き込みをして、総額100万円の賞金をゲットしよう！(*^^)v
　　　　万有サロン
　　　　　　http://jbbs.livedoor.jp/study/3729/
　　　　書き込み大賞の詳細
　　　　　　http://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1069922074/78-
　　　　書き込み大賞の詳細(資料倉庫内)
　　　　　　http://www2.tba.t-com.ne.jp/a-z/omake/banyu/taisho.htm
　　また、あらゆる疑問に関する質問を、携帯電話やメールでも受け付けています。
　　　　電話番号　080-4437-4187
　　　　メール　　aaa-zzz@tba.t-com.ne.jp

　　￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥￥

308 ：

通信したら膨大なデータはどういう仕組みで降りてくるの？
クライアントが『今はこれだけしか受け取りきれないよ』って時はどうするの？
データのポインタみたいなのをコネクション毎に保持しておくて
『ここまで送った』しおり代わりとするの？

309 ：

どの層の話？TCPレベル？カーソルレベル？プレゼンテーション層でのPostgresのデータ表現がどうなってるかは知らないけど

310 ：

データベースに限った話じゃないならスレ違い
TCPの確認応答とか、ウィンドウ制御の話。

311 ：

ああじゃあデータベース側は、気にせずいつも通り
最寄りのノードにデータ送る作業するだけで
後はOSI参照モデルを実装した外部システムが巧いことやってくれる算段なんですね

312 ：

状況がわからんけど
ミドルで全部受け取り済みな気がするなあ

313 ：

犯罪者個人に対してR状を違法派遣・偽装請負・偽装出向・多重派遣の被害者が作成(刑事Rは無料)　or 司法書士が代筆（料金は5万円ぐらい）※コピペ歓迎
↓
R状を【検察の直告班】に郵便局の内容証明付で送付（疎明資料・証拠にはＩＣレコーダー、スマホによる録音が適しています）
↓
審査　→　不受理　→　R状再提出または刑法 第193条で訴えを起こす
↓
受理　→　R事実を認め示談交渉（↓）　→示談成立　→　法廷相場50〜100万円の示談金　※示談拒否が良い
↓　　　　　　　　　　　　　　　　↓
事案化←　前科あり　←示談不成立（↓）→　示談外交渉→　犯罪者の年収半額×最大懲役年数の和解金支払い※推奨
↓　　　　　　　　　　　　　　　　↓
↓　　　　　　　　　　　　　　　起訴　→公判　→　罰金刑＝前科（起訴事実を認めてるため）→追討ち民事訴訟
↓　　　　　　　　　　　　　　　　　　　　
審査　→　起訴（強制捜査・留置場）→　公判　→　懲役刑などの厳罰（反省が認められないため）→追討ち民事訴訟
↓
不起訴、起訴猶予
↓
検察審査会法第３０条（検察審査会へ申し立て）→　起訴　→　起訴後は同上
刑法 第193条（公務員職権濫用）で検察事務官を刑事R　→　同上
◎R→R受理→示談交渉→厳罰を求め示談不成立→示談外交渉→和解金支払い・和解契約（公正証書・即決和解で秘密保持契約）
◎偽装請負・出向・違法派遣事件では派遣・出向先両方の代表者、役員、現場責任者にRできます。
前科がついた犯罪者が法人の代表であれば公的な入札からの排除、取引先や顧客との契約解除など社会的制裁・批判に晒されることから辞職または解任が妥当、役員・社員であれば懲戒を想定。
◎事業者内部の加害関係者による刑事R（刑事訴訟法239条1項）も可能です。
加害者本人、管理間接部門の社員が刑事Rに踏み切る場合も和解金による解決が妥当です。
注意：Rが受理されない理由
●３年間（※）の時効が過ぎたもの　※違法派遣
●同一事実について過去にR取消しがあったもの
●関連する民事訴訟を有利に導く目的の場合
●証拠が希薄なもの　※被害者が契約時に違法派遣・偽装請負・多重派遣と知っていても刑事Rは有効です。

314 ：

>>308
外しているかもしれないが、
ORDER BYして LIMIT で クライアントがほしい分だけSELECT するという話？
テーブルによっては漏らさずとることは出来ないけど。

315 ：

>>314
膨大なデータを、クライアントが遅延評価で受け取りつつ
クライアント側で専門の重い処理をしていくとき

316 ：

カーソルでいいじゃん

317 ：

クライアントの処理に合わせてサーバからデータを数行ずつ取得して行きたいとかならそうだな

318 ：

Rの趣旨
　被R人は、以下に該当すると考えるので、被R人の厳重な処罰を求めるためRします。
　職務経歴書を提示した事前面接を実施　または　偽装請負　または　偽装出向
　　労働者派遣法第26条（契約の内容等）、職業安定法第44条（労働者供給）に違反
　多重派遣・多重出向
　　労働基準法第6条（中間搾取の禁止）に違反
疎明資料
　事前面接日時、場所、出席者、資料のコピー、音声記録
　就業場所・就業期間・就業時間
　指揮命令
　　指示を誰が行っているかの記録、音声記録
　仕事で使う道具や、資材の負担（所有）のあり方
　　業務で使用しているパソコン・備品などの所有者
　契約書
　　請負、雇用契約書、出向指示など書面のコピー
刑事Rガイダンス　
★痴漢も民事でなく刑事事案ですが、裁判所が和解金を被害者に支払わせて解決するのが絶対的過半数です。和解で解決しない事案、つまり公訴までいって判例となる事例を探すほうが難しいことでしょう。
★録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
★R状を検察に提出しても受理されなければ加害者側には知られることはありません。不受理の場合は何事も起きてないように粛々と振る舞ってください。
★Rを取り下げるとき検察に提出した資料は全て返却されます。また検察があなたが提出した証拠をあなたの許可なく裁判の証拠として使用はできません。Rを取り下げたのちの録音資料には当事者の立場が失われるため証拠能力はありません。
★和解時にRした事実は秘匿事項となります。犯罪者が秘密保持契約に違反した場合の損害賠償金は「即決和解」か「公正証書」で最低5000万円〜にしましょう。支払いを拒否すれば強制執行手続きを（裁判不要）してください。
★派遣会社や事業会社が同業者に貴方の情報をリークしたなら同業者（又は競合他社）に弱みを握られることになります。
余程信用のおける相手でなければ、リークはできないでしょう。信頼のおける方にしても、その方の口が軽ければ、いずれ事実は分かります。
★リークの情報を得た事業者のなかには、リークの事実を貴方に教えてくれる方がいるかもしれません。その際は損害賠償金で得たお金の３割程度を謝礼金として渡してください。

319 ：

※コピペ歓迎です。
違法派遣（偽装請負・多重派遣・偽装出向・事前面接等）についての刑事罰
【R権者＝業務委託、準委任、共同受注、業務請負契約および特定派遣（契約・正規）、一般派遣、正規社員】
�@職業安定法第４４条の労働者供給事業の禁止規定に違反（1年以下の懲役または20万円以下の罰金）
　■偽装請負・多重派遣・偽装出向・多重出向
　■事前面接（顔合わせ・面談・職場見学等）と履歴書・職務経歴書・スキルシート等提出による労働者の特定(※）
（音声録音で立証可能）
�A労働基準法第６条（中間搾取の禁止） (1年以下の懲役又は50万円以下の罰金)
　■多重派遣・多重出向
※違法派遣（派遣労働者の特定）→派遣法で認められた派遣労働者ではない→労働者供給事業→職業安定法44条違反というの
が前提となる法解釈となります。派遣法における罰則が軽微なのは法律の不備や労働者軽視などが原因ではありません。
違法派遣は全て職業安定法44条で裁くことが可能なため、刑罰の重複を避けるために派遣法には軽微な罰則（主に裁量行政による）しかないのです。
使用者に有利な民事訴訟や労働関係諸局への通報等の対極にあるのが書面（R状）による刑事R（※R先は検察の直告班）です。
労働関係諸局への通報・斡旋による軽微な「適正化」や監督・指導に対して、法律に定められた刑事罰を問うことになり、
違法派遣業者にとって有罪は考えられる限り最大の処罰となります。同時に刑事罰を受けた
担当者が取引先に与える悪印象を考慮すれば、通常会社側はRが受理された時点でR取り下げに
動くのが妥当でしょう。懲役、前科がつく刑罰が下される可能性から、R取り下げの和解金は高額となることが多いのです。
Rの流れとしては、
刑事R⇒R受理⇒R取下げ要請⇒取下げ和解金入金⇒R取下げ
となります。Rの懲役刑適応は犯罪者個人に対してのみですので、Rする対象は
派遣先・派遣元 社長
派遣先・派遣元 責任者・管理役員・取締役
派遣先・派遣元 人事管理担当者・人事管理役員・取締役
が妥当です。刑事R取り下げの和解金額は犯罪者個人と交渉するとよいでしょう。（R状は人数分提出する必要あり）

320 ：

PostgreSQLで、あるSQLが「条件で絞ってからjoinしている」のか「joinしてから条件で絞っている」のかを調べる方法ってありますか。
あるいはexplainで分かるとして、explainの出力のどれを見ればいいですか。
10個くらいjoinしているけども、条件で絞ってからjoinすれば (レコード数が
少ないので) 大した時間がかからないだろうと思われるSQLがあります。
しかし計測してみるとそれなりの実行時間がかかっていました。joinを外したところ、大幅に高速化できました。
なので、もしかしたら内部では「joinしてから条件で絞っている」のではないかと
疑っています。それを調べたいです。

321 ：

sql書いてるならexplain見ればだいたい把握できるだろ
理解力・想像力が乏しいのであればpgadminのグラフィカルな奴でも使えば。

322 ：

>>320
joinのために使われたアルゴリズムによる。
問い合わせ計画の読み方を一通り理解すればわかると思う。
http://www.postgresql.jp/document/9.2/html/using-explain.html

323 ：

>>322
ありがとうございます。
explainで調べたところ、limitより先にjoinされてました。
これだと相当な量のレコードがjoinされてしまい、遅くなって当然でした。
そこで今度は、joinより先にlimitで絞り込む方法について教えてください。
手元で試したところ、副問い合わせを使って先にlimitで絞り込み、
その結果を使って外側でjoinすると、確かに速度は改善されました。
しかし副問い合わせを使うよう変更したSQLは、カラム数が多いこともあって
内側と外側のselect文で重複したカラム名がたくさんでてしまい、
メンテナンス性の悪いSQLになってしまいました。
できればもとの素直なSQLのまま、joinのタイミングだけlimitよりあとにするよう
変更したいです。
そのようなことはPostgreSQL (9.1) でできますか？

324 ：

一応できると答えておく。
やり方は自分で考えろ。

325 ：

>>323
ワイルドカード"*"を使えばいいんじゃないかな。

326 ：

>>324
こういう負け惜しみ回答がつくということは、joinのタイミングを指定することがPostgreSQLではできないということですね。
>>325
いえ、ワイルドカードは使えません。たとえば：
select x.a, x.b bar.name, baz.name
from (select a, b, bar_id, baz_id from maintbl where a>=:var1 and b<=:var2) as x
join bartbl on x.bar_id = bartbl.id
join baztbl on x.baz_id = baztbl.id
ここでワイルドカードを使うと、内側のSQLでのみ必要なカラムが外側にも出てきてしまうので、だめです。
select x.*, bar.name, baz.name
from (select a, b, bar_id, baz_id from maintbl where a>=:var1 and b<=:var2) as x
join bartbl on x.bar_id = bartbl.id
join baztbl on x.baz_id = baztbl.id

327 ：

>>326
それで、limitをどこに書くって言ってるわけ？

328 ：

そもそも limit で絞り込んで join するのと、join して limit するんじゃ結果が違うことがあるから、
「joinのタイミングだけlimitよりあとにする」なんてできる DBMS はないと思うが…

329 ：

>>327
説明不足でしたので、サンプルのSQLで説明します。
-- もとのSQLは、joinしてからlimitで絞るので遅かった
select main.id, main.value, main.foo, main.bar, main.baz,
　　　aaa.name, bbb.name, ccc.name, ddd.name, eee.name
from main
join aaa on main.aaa_id = aaa.id
join bbb on main.bbb_id = bbb.id
join ccc on main.ccc_id = ccc.id
join ddd on main.ddd_id = ddd.id
join eee on main.eee_id = eee.id
where main.value >= :value_from
　and main.value <= :value_to
order by main.value
limit 10
offset 0
-- これを、limitで絞ってからjoinするように変更すると速くなった
-- しかしselectで指定するカラム名に重複が多く、メンテしにくくなった
select tmp.id, tmp.value, tmp.foo, tmp.bar, tmp.baz,
　　　aaa.name, bbb.name, ccc.name, ddd.name, eee.name
from (
　 select main.id, main.value, main.foo, main.bar, main.baz,
　　　　 main.aaa_id, main.bbb_id, main.ccc_id, main.ddd_id, main.eee_id
　 from main
　 where main.value >= :value_from
　 　and main.value <= :value_to
　 order by main.value
　 limit 10
　 offset 0
) as tmp
join aaa on tmp.aaa_id = aaa.id
join bbb on tmp.bbb_id = bbb.id
join ccc on tmp.ccc_id = ccc.id
join ddd on tmp.ddd_id = ddd.id
join eee on tmp.eee_id = eee.id

330 ：

>>328
>そもそも limit で絞り込んで join するのと、join して limit するんじゃ結果が違うことがある
それはその通りなのですが、結果が同じ場合もあるわけで、その場合は人間が判断してjoinのタイミングを指定できるようにしてくれたほうがうれしいです。

331 ：

limit以外に絞り込む手段は無いの？
最終結果以外でlimitが入るのは何かがおかしい。

332 ：

>>331
>limit以外に絞り込む手段は無いの？
where句でも絞ってますよ。
ただwhereで絞っても数百〜数千件くらいまでしか絞れないです。
order+limitでは10件とか20件に絞りこみます。
>最終結果以外でlimitが入るのは何かがおかしい。
そうなんですか？
まあ別に「最終結果以外でlimitを使いたい」というわけではなく、「可能な場合はlimitを先に実行してからjoinを行う」ことをPostgreSQLが自動的にやってくれるくらい賢ければそれでいいです。
今はやってくれないので、仕方なく人間が指定するしかなくて、その方法を質問しています。

333 ：

>>330
>>329 のクエリが両方常に同じ結果になるというのなら、mainとaaa〜eeeまではすべてn対1対応になっているのだろうから、
left joinの外部結合に書きなおせばいい。

334 ：

>>326
> ここでワイルドカードを使うと、内側のSQLでのみ必要なカラムが外側にも出てきてしまうので、だめです。
俺は >>325 じゃないから、>>325 の本心はわからんが、内側のこと言ってるんじゃないのか
select x.a, x.b bar.name, baz.name
from (select * from maintbl where a>=:var1 and b<=:var2) as x
join bartbl on x.bar_id = bartbl.id
join baztbl on x.baz_id = baztbl.id

335 ：

>>329を見る限り駆動表がmainでlimit 10が普通に効きそうなもんだが。
explainの先頭の表がmainでなかったり、nested loop joinじゃなくて
hash joinが出てきたりしたら、統計がとられていないかjoinするテーブルの
idにindexが張られていないことが思いつくが。
あと、joinするテーブル数が12以上だったらgeqoで最適化がはしょられているとか。

336 ：

>>335
329では「order by main.value」と書いてますが、実際にはここがちょっと複雑な計算式になってます。
そのせいでプランナがうまく効いてくれないのでしょうか。
また副問い合わせにする前のSQLだと、explainの先頭は Limit になってます。
hash joinは出てこずNested LoopとIndex Scanがばかりです。
joinするテーブル数は12まではいかないですし、どれもidはprimary key (sequence) なのでindexは作成されてます。

337 ：

その複雑な式でインデックス作るとか？

338 ：

win8pro 64bit
postgres 9.2
の環境でログのローテーションが機能しないんですが
同様の症状の方いませんか？
ファイルサイズ指定でローテーションしようとしてます
設定は何度も確認しました
win7 postgres8.4では動いてて
同じ設定なのですが

339 ：

>>338
基本的な問題の切り分けでもやってみたら？
OSかPostgreSQLのバージョンをどちらか合せてやってみてどうなるか

340 ：

win8 64bit
postgres9.1ではローテーションが機能しました。
9.2のバグ？
9.1に戻すか、次を待つか考えます
とりあえず報告まで

341 ：

パワハラ犯罪にたいする刑事罰(※本投稿のコピペ歓迎です)
人事原則
１　現行法では、社員が仕事を怠けたり、能力不足、就業規則違反、目標を達成できなくても解雇をしたり叱責することは違法です。どんな駄目社員、嘘つき社員、怠け者も定年まで解雇が違法なのが現行の正社員制度です。
２　パワハラは社風にあわない社員、成績の振るわない社員を自主退職に追い込む言わば人事的措置として用いられることが多い。
※違法な解雇の和解金相場は、労働審判で３ヶ月、通常裁判で１年以上の報酬、さらに社員が和解を拒めば復職が可能です。弁護士への着手金は12〜15万円、和解拒否なら20〜50万円程度。
人事部・ホットライン・御用組合へ直訴
メリット：　一時的緩和や人事異動
デメリット：　役員へ情報筒抜け、危険分子の烙印（情報漏洩がホットライン直訴者に多いのは人事部の常識）、パワハラ放置で自主退職に追い込まれる
民事訴訟・調停・労働審判
メリット：　損害賠償
デメリット：　裁判費用、解雇措置、民事不介入で刑事事案化を阻止、長期係争、パワハラ上司の継続雇用
刑事R
メリット：　１パワハラ上司の解雇・懲戒、または２多額の和解金、１と２どちらでも被害者の雇用は維持
デメリット：　人事異動（出世コースから外れる）
◎録音は一方の当事者が取る限り合法です。※加害者に録音の同意を求める必要はありません。
◎R受理後の和解金は加害者の資産・収入に応じて変えてください。犯罪者の昨年の年収の半額程度×最大懲役年数が妥当です。
◎パワハラの被害についてのRは１侮辱罪２脅迫罪３強要罪４威力業務妨害罪５傷害罪の順序で行ってください。警察・検察の協力（犯罪者の自宅・職場の強制捜査、留置所勾留）により罪の立証が楽になります。
◎刑事Rした社員を解雇したり処遇面で著しい差別を行うことはないでしょうが、出世や管理職以上の昇進の可能性はあきらめるべきでしょう。
◎刑事Rは民事訴訟と違って裁判による被害者への2次被害にありません。検察庁が被害者に代わって訴えをおこすので、無料で、時間と手間もR状をかくことと音声録音を残すだけです。
◎和解契約（公正証書・即決和解）ではRした事実は秘匿事項となります。犯罪者が秘密保持契約を違反した場合の損害賠償金は、最低5000万円〜にしましょう。

342 ：

すいません。pg_hdaを以下のように設定しているのですが、
外部に対してもリッスンしています。
local all all password
host all all 127.0.0.1/32 password
あと、postgresql.confのlisten_addressesはコメントアウトしています。
ここ以外に変更しなければならない場所はあるのでしょうか？
宜しくお願いします。

343 ：

あ、すいません。pg_hdaではなく、pg_hba.confでした。

344 ：

postgresql.confの設定をミスってるか、外部からアクセスできると勘違いしてるかのどっちかじゃないの？

345 ：

>> 344
postgresql.confは未設定で、
外部からnmapで見たら開いていて、更にTELNETでもつながる状態です。

346 ：

>>345
何言ってるのかわかんない。
grep listen_address /path/to/postgresql.con
と
netstat -a | grep postgres
の結果を貼って。

347 ：

まさか、postgresql.confを変更してから、デーモンを再起動してないとかいうことじゃないだろうな

348 ：

>> 346
以下のようになりました。
[grep listen_address postgresql.conf]
#listen_addresses = 'localhost' # what IP address(es) to listen on;
[netstat -a | grep postgres]
tcp 0 0 *:postgresql *:* LISTEN
tcp 0 0 localhost.localdo:35514 localhost.lo:postgresql TIME_WAIT
tcp 0 0 localhost.localdo:35519 localhost.lo:postgresql TIME_WAIT
tcp 0 0 localhost.localdo:35517 localhost.lo:postgresql TIME_WAIT
tcp 0 0 localhost.localdo:35516 localhost.lo:postgresql TIME_WAIT
tcp 0 0 localhost.localdo:35512 localhost.lo:postgresql TIME_WAIT
tcp 0 0 localhost.localdo:35513 localhost.lo:postgresql TIME_WAIT
tcp6 0 0 [::]:postgresql [::]:* LISTEN
宜しくお願いします。

349 ：

>>347
一応再起動はしています。

350 ：

>>348
確かに、postgresql.confでコメントアウトしていて、*でlistenしてるな。
うーん、わからんわ。ごめん。
PostgreSQLを複数インストールしていて、編集したpostgresql.confが今起動しているサーバのものじゃ
ないのかなぁ。

351 ：

>>342
> すいません。pg_hdaを以下のように設定しているのですが、
> 外部に対してもリッスンしています。
で、どうしたの？　って話なんだけど。何を困ってるのか分からん。
クライアントから接続できないとかなら、各種ログ出せば？

352 ：

>>351
localhostからのconnectだけを受け付けたいのだが、それができないというのが困ってることだと。
もちろん、Firewallで制限したり、pg_hba.confで制限したりはできるけど、localhostだけでlistenできた方がいいでしょ。

353 ：

>>350
> PostgreSQLを複数インストールしていて、編集したpostgresql.confが今起動しているサーバのものじゃないのかなぁ。
念の為確認してみます。
>> 351
ローカルからのみの接続にしたいのです。

354 ：

例えば、VPSでWebアプリが使用する為にPostgreSQLを起動したいんだけど、デフォルトで
全IPアドレスからのconnectを受け付けることしかできないんじゃ困るでしょ。

355 ：

>>350
今findしてみたらpostgresql.confは１つしか存在しませんでした。

356 ：

>>355
pg_hda.confに書いてあるのは >>342 だけで後は全部コメント行なの？
postgresのサービスを再起動して設定を有効にした？
外部からpostgresにアクセスした状態で
netstat -a | grep postgres
とすると結果はどうなる？

357 ：

348のnetstatの結果を見ると、
ひょっとしてWebアプリとかで内部経由でpostgresにアクセスしようとしてる？
postgresのpg_hda.confの設定は認証の許可を設定できるけど、ポートを閉じたりできないし、telnetのアクセスにも関係ないよ。

358 ：

psqlで接続してSHOW listen_addresses;してみる
起動オプションでパラメータを上書きしてるんじゃね？

359 ：

色々とありがとうございます。
それぞれ確認してみますので、少し待って下さい。

360 ：

どのレイヤーで弾かれてるのかまず明らかにしろよ

361 ：

どのレイヤーで弾かれてるのかまず明らかにしろよ

362 ：

大事なことなので連投してしまいました
すみません

363 ：

アホが一人いるだけで普段の数倍盛り上がるな。

364 ：

>>351のことかなぁ

365 ：

レコードの有無を調べるSQLは、
　　SELECT 1 FROM <table_name> WHERE <条件>
で良いのでしょうか？

366 ：

>>365
SELECT 1
じゃ常に１が返るだろう。
SELECT COUNT(1) > 0 FROM ・・・
とか？

367 ：

って０件で判別するのなら　1 だけでいいか

368 ：

count使うと遅いですよね。たぶん。
365の方法が最速な気がしないので質問する次第です。
言葉が足りず、すみません。

369 ：

limitでも付けなきゃcountとたいして変わらんだろ

370 ：

existsつかってみたら

371 ：

>>369
その通りですね！

372 ：

INDEXありゃ一発だしな
exists はlimitあわせればなんとか

373 ：

>>348
postgresql.conf の listen_address をコメントアウトしてるみたいだけど
逆にコメント外して listen_addresses = 'localhost' にしたらどうなるの？
それでも netstat が変化しなかったら、読まれてないか上書きされてるかのどちらか
localhost 以外にも自分の普通のIPつけるとかしてみたらいいんじゃないかな
あと netstat には -n つけるのがオススメ

374 ：

で、原因はなんだったの？

375 ：

NAPTで思ってたのと違うホストにつながってた可能性もあるな
>>356はその辺も解決できる提案だとおもうけど、結果はられてないし結論は不明だけど。

376 ：

VACUUMが回収できる行だと判断する条件について質問があります。
実行中のトランザクションの最も古いxidの値が、
行のxmaxより大きい場合にVACUUMしてよい行と判断していると考えてよいですか？

377 ：

ストリーミングレプリケーションの、スレーブで実行する参照処理には、トランザクションIDが発行されないようですが、
行の可視性はどのように保証しているのでしょうか？
スナップショットを取得して判断している？マニュアルを読んでも、スナップショットについて理解できなかったので、可能であればスナップショットについて教えてください。

378 ：

ソース読めばエエやん。

379 ：

スレーブにはトランザクションって概念が無いじゃない。

380 ：

PostgreSQLのレプリケーションは非同期だから
確実に最新の値を読む必要があるならばマスターを読みにゆくしかないのでは？

381 ：

datetimeの表示で、秒未満を切り捨てて表示するにはどうしたらいいでしょうか。
たとえば
select created_at from exampletable where id = 1;
を実行したら
2013-01-01 12:34:56.389940
と表示されます。
これを
2013-01-01 12:34:56
と表示させたいです。

382 ：

単にピリオド含めて右側を捨てるような文字列操作でいけるんちゃう?
少数以下一位で四捨五入とかしたいならもうちょっとややこしいだろうけど。

383 ：

そんな定番な質問は調べればすぐに出てくるでしょうに・・・
to_char(created_at, 'YYYY-MM-DD HH24:MI:SS') でいいんでない？

384 ：

TIMESTAMP(0)でキャストするとかね。
元からテーブル作成時にそうしてしまう手もあるけど。
SELECT NOW()::TIMESTAMP(0);
とか
CREATE table (t TIMESTAMP(0),・・・・
とかね

385 ：

おっと、
CREATE TABLE table名・・ね

386 ：

>>382-383
説明がたりませんでした。
いちいちキャストとか変換とかせずに、一括して秒未満を切り捨てて表示するような方法はないでしょうか。
>>384
テーブルスキーマでそのような指定ができるんですね。なるほど。
うーん、スキーマを変更する権限が自分にあればよかったんですけど。

387 ：

オプション替えてPostgreSQLをビルドしなおすとか？

388 ：

というか、君は何ができるの？
あれもできない、これもできないって後から言うくらいなら
どこまでできるのか先に提示してよ。

389 ：

VIEWが作れるならVIEWはさめばいいし、UPDATEできるなら
一発で今のデータの小数点以下を消してしまえばいいし

390 ：

select count(*) と select(id) では前者のほうが速いようなんですが、これはよく知られたことなんでしょうか。
PostgreSQL 9.1で実験したら：
select count(id) from users; -- 45ms
select count(*) from users; -- 34ms
自分の間違いじゃないかと思うんですが、もし違いがあるなら教えてください。

391 ：

昔ならともかく、今は同じじゃないかなぁ。
ちなみに順番逆にしても*の方が速い？

392 ：

>>390
同じだと思うよ。
参考URL:
http://wiki.postgresql.org/wiki/Slow_Counting/ja
ちなみに、上のページにも書かれているけど、9.2からはインデックスオンリースキャンが実装されているので
事情が違う。

393 ：

9.2以降のCOUNT(*)におけるインデックスオンリースキャンに関する情報：
http://lets.postgresql.jp/documents/technical/9.2/1

394 ：

>>391
何度か実行してみた結果です。順番変えても変わらず。analyzeしてもそう。
>>392
> 同じだと思うよ。
ですよねー。
> 9.2からはインデックスオンリースキャンが実装されているので事情が違う。
9.2からは count(id) と count(*) のどっちが速くなるんですか？
本来ならインデックスオンリースキャンでも変わらないようにみえます。実験してないけど。

395 ：

>>394
> 9.2からは count(id) と count(*) のどっちが速くなるんですか？
9.2で何の事情が違うというのは、9.1までのCOUNT(*/id)との動作が違うということで、どちらかが
どうということではないよ。
> 本来ならインデックスオンリースキャンでも変わらないようにみえます。実験してないけど。
そう、インデックスを使えるなら、COUNT(*)もCOUNT(id)も9.1より速くなる。

396 ：

>>395
> COUNT(*)もCOUNT(id)も9.1より速くなる。
そういうことを聞きたいんじゃなくて、count(*)とcount(id)で速度に違いはあるのかということです。
9.2になっても、違いはないはず -- Yes or No?

397 ：

どちらが速くなるかと聞かれたので、どちらも速くなるとコメントした。
COUNT(*)とCOUNT(id)は、インデックススキャンが使われるなら、やっぱり同じだろう。

398 ：

実行計画はどちらも同じなの？

399 ：

ソースからmakeして、バイナリしか残ってないんだけど
configureオプションに何を指定したか、バイナリのオプションで表示できないのかな？

400 ：

pg_config も無いの？

401 ：

>>400
ありました。そしてオプション表示されました。ありがとうございました。
http://www.postgresql.jp/document/8.4/html/app-pgconfig.html

402 ：

9.3出たら呼んで

403 ：

pg_trgm更新遅くなりすぎて使い物にならん

404 ：

INSERT SELECTした時、SELECT部分で帰ってきたデータを取得する事って出来ますか？
テーブルA,B,Cてあって、BはAのIDを、CはBのIDみたいに親子関係に有った時、
テーブルAで採番されたIDを持つコピー後データをBに、テーブルBで採番されたIDを持つコピー後データをCに
て感じにしたいんだけど、今のテーブル構造だとコピー元、コピー後のマッピングができなくてどうにも出来ないんだ。
それぞれのテーブルにold_idみたいに、コピー前IDを持つようにしたほうが早い？

405 ：

バージョン書いてないから対応してるかどうかわからないけど、returningで調べるといいよ

406 ：

404じゃないけど。
この板、ほんとスキルが高くて親切な人が多いなあ。
Letsの人かな。
感謝してます。

407 ：

>>405
こんな物が有ったなんて！
バージョンは9.2なので使えそうです
本当に有難うございます！

408 ：

9.0でラージオブジェクトを含む初期データをpsql -f でファイルから読み込んで作ろうと思っています
lo_importで画像を登録するにはpostgresユーザー権限が必要だけど
実際そのDBを使うのはhogeユーザーっていう状況です
importした後にalter lrage objectを使ってhogeユーザーに変えようと思っているんですが、
この時lo_importで発行したoidを変数的なものに入れておくことは出来ないでしょうか
今やっている方法としては、lo_import('ファイル', 1);
alter lrage object 1 owner on hoge
てかんじでIDを直打ちしているんです

409 ：

lo_create でつくるとか？
一時テーブル作って、INSERT文でlo_import 使えばそのテーブルにid入ることは入るけど
そう言う手はどう？

410 ：

セセセセキュリティホールが見つかったとか聞いて飛んできました！
だだだ大丈夫ですかぁあああ！？

411 ：

認証不要でDB破壊できちゃうみたいだからかなりヤバげ。
外に晒してなくて信頼できるところからしか接続されないようになってるなら
それほど影響ないかもしれないけど。

412 ：

おまいら、ご存じでしたら教えてください。
ストアド(pl/pgsql)の定義を厳密にチェックするように設定出来ますか？
lintに相当するチェック機能はありませんか？

413 ：

元々Cとかに比べるとかなり厳密。

414 ：

https://github.com/okbob/plpgsql_lint
こういうのとかどうかね

415 ：

javaのほうから誘導されてきました。
windows7Pro
PostgreSQL9.2.1
で開発しています。
教えてください。
javaでsqlのinsert文を発行するとき
String str1 = (String) table.getValueAt(row, 1);
String str2 = (String) table.getValueAt(row, 2);
String str = "insert into test_numbers (number, date) values ('"+ str1 + "', '" + str2 + "')";
(1)str1が'1'でstr2が'20130427'ならinsertできて
(2)str1が'1'でstr2が'2013/04/27'ならinsertできないのですが
どうしてなのでしょうか？
コンソールから上記sqlを発行すると、(1)も(2)も問題なく処理されます。

416 ：

>>415
コンソールはクライアントのロカールを見て、日付の書式を自動的に年/月/日に
設定してくれている。
Javaからの接続はこの設定を変えないので、サーバ側で指定された書式(たぶん
月/日/年になっている)が使われている。
年/月/日形式の日付書式を使うには、
サーバのpostgresql.confにある設定を
datestyle = 'iso, ymd'
とするか、毎回接続開始時に
set datestyle to 'iso, ymd';
とすればよい。

417 ：

どのデータベースでも言えることだけど、
商用ソフトとして作ってるなら、日付書式は予めプログラム側でやっとく方が良いよ。

418 ：

to_date('$str2', 'yyyy/mm/dd') かな。

419 ：

日本人の払った貴重な血税から
ゴキブリ在日朝鮮人に生活保護が支払われている
ゴキブリ在日朝鮮人の一家族で年間６００万円である
ゴキブリ在日朝鮮人の２人に１人は生活保護だ
これより安い給料で働いている日本人が
少ない給料から支払った税金が
ゴキブリ在日朝鮮人の生活保護になっている
ゴキブリ在日朝鮮人は生活保護をもらって
感謝もせず　当然のような顔をして
毎日パチンコをして遊び暮らしている
ゴキブリ在日朝鮮人の犯罪者も非常に多い
ヤクザの２人に１人はゴキブリ在日朝鮮人だ
日本社会の寄生虫　ゴキブリ在日朝鮮人
日本から出て行け！　ゴキブリ在日朝鮮人

420 ：

>>416
>>417
>>418
ありがとうございます！

421 ：

PostgreSQL 9.3-beta1

422 ：

本来の使い方ではないかもしれませんが・・・
integer型1カラムで主キーを設定してテーブルを作成しました。
ここに特定のIDをINSERTできれば、排他ロックを取得、
エラーが起これば、他のクライアントで排他処理中としようかと。
INSERT INTO TESTTABLE SET ID=123 ;
とSQLを投げて、エラー(例外）をキャッチしているのですが、
もっとスマートな方法はありませんか？
エラーが返ってくるのではなく、INSERTが成功すればTRUE、
失敗すればFALSEを返すようなSQL文ってないでしょうか？

423 ：

INSERTしないでSELECT FOR UPDATE NOWAITしろよ。

424 ：

FOR UPDATEを知らなかった・・・　お恥ずかしい。
ちと調べてきます。

425 ：

>>421
起こせよ寝坊しただろ

426 ：

ｂｅｔａ版だからまだ寝てていいよ。

427 ：

おれもbetaだからまだいいかと思ってた

428 ：

単にbetaと付いているだけで気にせず使ってねっていうソフトも結構多いけど、
PostgreSQLはそういうソフトじゃないしねい

429 ：

betaだからと気にしながらも、どんどん使えってことか。

430 ：

7.3で、毎日vacuumdbしてんだけど、最近重い。
年に一度くらいは、pg_dumpしてpsqlリストアとかすべき？
あんまり関係ないですかね？

431 ：

何が重いの？vacuum？

432 ：

参照系全般です。

433 ：

reindexはしてないの？

434 ：

なんとreindexを定期実行しなきゃいけないのか。
無知だったわ。
でも止められないシステムだから、気軽にできないなぁ

435 ：

7.3ならダンプレストアするのが早いかもなー

436 ：

古いバージョン使い続けている事自体が問題かもな。

437 ：

もちろんそれは気になるけれど、それ自体が問題というのはちょっとな

438 ：

止めずに使ってるんだから大したもんだよ。
他所だと止めてない、っていうとパッチ当ててないのか？とか批判されそうだけど。

439 ：

それは環境によるとしかいえないなぁ
非難すべき状況かもしれないし、そうじゃないかもしれないし

440 ：

postgresql 9.2でも、textsearch_senna は問題なく使用できますか？

441 ：

世の中何でも24時間稼働という風潮になってきていて
その核となるDBMSは止められないことが多いからなあ…
セキュリティ確保のためオンライン自動アップデート系の
メンテ方法も採用できないことも多いし…
運用はいつの世でも大変だ

442 ：

>>441
いまどき運用サイドから見て止められないシステムを作っちゃうのが悪いわ。

443 ：

孫請けだから、要件通り7.3を止めずに動かしてお金もらうだけだわ。
怖いからFWや別のレイヤーで色々ガチガチには固めてるけど。
トラブっても責任逃れする準備も含めて周到にやってる。
で、ここの人達はみんな9.2とか使ってるのか。裏山

444 ：

有効に使われているシステムほど、古くなってもバージョンアップが
できないですよね。

445 ：

>>440
9.2どころか8.3でもダメじゃなかったっけ？

446 ：

え？
これだけじゃレプリケーションは勿論駄目だけど一応使えてるよ

447 ：

>>440
textsearch_jaだけど若干のソースの書き換えと文字コードをutf-8bom無しへの変換でいけたよ。
ソースの書き換えはsqlの大文字を小文字に直した程度だったと思う。

448 ：

>>443
うちは8.2だわ

449 ：

自動バキュームの恩恵を受けられる8.3以降を使わないのは勿体ない。

450 ：

更新も検索も常に走るようなシステムだとキツいからずっとoffったままだなauto

451 ：

もったいないつーても
止められない事情と天秤にかけての判断になるからな
無理矢理止めて入れ替えてトラブったら目も当てられん
現実は厳しいぜ

452 ：

もとい、朝方だけ落ち着くのでその時間にvacuumするのがやっぱ運用しやすかった
いちいち調整するのも大変だし、
autoじゃ拾いきれなくてどっちみち手動vacuumするしかなかった。

453 ：

9.0ぐらいからかvacuum自体あまりしなくてよくなったんだっけ。

454 ：

HOTが有効な更新が多いならバキューム自体あまり気にしなくていいはず。

455 ：

最近は参照があるたびにcountカラムをインクリメントするような事してるけどデッドタプル結構貯まるんだよなぁ。
まぁ以前のバージョンに比べればデッドタプル多少貯まってもパフォーマンスに影響そんな無いみたいだから気にしてないけど。

456 ：

8.3よりも前のバージョンの自動バキュームは何がダメなの？

457 ：

>>456
たしか自動バキュームのワーカープロセスが1つしかないから
大きいテーブルの自動バキュームが走ると、それが終わるまで
他のテーブルへの自動バキュームが出来なくなるとかだった気がする。
で、8.3からは複数ワーカープロセスが動けるようになった。

458 ：

>455
一般論で言えば、テーブルにFILLFACTORを設定すれば、そんなにデッドタプルが溜まることはなくなるはず。

459 ：

テス

460 ：

初心者質問で恐縮です。
バージョン9.2です。
例えばwhere id=? and code=? という条件を
codeのパラメーターの値が無ければすべて抽出するという書き方はありますか？

461 ：

あるよ。

462 ：

ヒントも書いとく。
WHERE ID=? AND ( X )
Xの部分は自分で考えろ。

463 ：

>>462
（）で括っているのがヒントですか？

464 ：

code = ? or code is nullかなあ

465 ：

>>464
パラメーター値がある時は抽出できますが
すべて抽出はできませんでした

466 ：

IF文使えばいけるけど、プログラムで実行するSQL文制御した方がいいよ。

467 ：

select * from R where id=? and code=? or not exists (select * from R where id=? and code =?)

468 ：

書いてくれた方ありがとうございます！
>>467 だとほんとにすべて抽出されます。
私の書き方がまちがっていたようです。
すいません。
例えば
where id=? and code=? という条件で
code=0 の時
where id=?
code=1以上 の時（値があるとき）
where id=? and code=?
と、したいのです。

469 ：

>>468
>>462

470 ：

whereにor使えること知らないの？

471 ：

ORを知らないんだろ。

472 ：

>>468
もしパラメータがないことを表す値がcode = 0のようにわかっているなら
select * from R where id=? and (code=0 or code=?)
そうでないなら、467にかっこを加えて
select * from R where id=? and (code=? or not exists (select * from R where id=? and code =?))

473 ：

うちの会社じゃSQLの新人(中途でも)に１日目に教えるような簡単なことなのに。

474 ：

>>472
できました！ありがとうございます。
これって相関サブクエリでcode=?以外を抽出するって意味でしょうか？

475 ：

書き忘れましたが、下記のSQLでです。
select * from R where id=? and (code=? or not exists (select * from R where id=? and code =?))

476 ：

>>473
外野は黙ってろ
そういうくだらない茶々入れが荒れる元になるんだ
お前のところの教育がどうこうなんてこの流れで言うことか
話の流れに沿わない書き込みはするな

477 ：

そういう口調も荒れる原因になったりするんだけどね。
穏やかに行こうよ。

478 ：

>>474
いや相関ではない。
手続き的に言えば
最初にサブクエリが実行され、その結果（true/flse）に置き換えて
メインクエリが実行されるというイメージ。
（よっぽど駄目なDBMSでなければ）

479 ：

>>478
丁寧な説明とわかりやすい指導ありがとうございます。

480 ：

ホントにできたのかな…

481 ：

だけって言うのもあれなので、、
前者は質問者の話の流れで行くと、code=0は常に偽となるだろうから
select * from R where id=? and (code=0 or code=?) は
select * from R where id=? and (FALSE or code=?) となって
select * from R where id=? and code=? と同じかなと。
後者なら回りくどいけど、動きそうか。

482 ：

>>461 = >>462だけど、>>481には正解がないよ。

483 ：

わかってる

484 ：

>>481は、間違い？

485 ：

>>484
あなたが希望したとおりに動いてるのなら正解
そうじゃないなら間違い

486 ：

select * from R where id=? and (code=? or not exists (select * from R where id=? and code =?))
このsqlで、
code=0 すべてのレコードを抽出
code=1 codeが1のレコードを抽出
code=2 codeが2のレコードを抽出
というかたちで希望どうりの動きができています。

487 ：

code=ナントカって、渡すパラメータのことを言ってたのか？
だったらサブクエリなんか使わんでも
select * from R where id=? and (code=? or ?=0)
でいいんじゃね？

488 ：

>>487
正解

489 ：

だね。何で回りくどい書き方をしたのか

490 ：

>>460

491 ：

？

492 ：

？？

493 ：

文字化けがひどいな。

494 ：

？？？

495 ：

おまいら、質問です。
CREATE FUNCTIONでストアド作る時にフィールドやらテーブルの存在チェックをする方法はありませんか？
もしくはビューやストアドに使われてるフィールドやらテーブルの存在チェックを一括で実行する方法はありませんか？
デフォルト設定のMacOSX用9.2.4と、Windows版pgAdminIIIの組み合わせでストアドを作っています。
設定変更でチェック出来るなら変更します。
今は1個1個実行してバグ出ししてます。
(命名規則違反が見つかった時とかは修正後ストアドのテストやり直し＞＜；；)

496 ：

>>495
> CREATE FUNCTIONでストアド作る時にフィールドやらテーブルの存在チェックをする方法はありませんか？
無い。
> もしくはビューやストアドに使われてるフィールドやらテーブルの存在チェックを一括で実行する方法はありませんか？
無い。
> (命名規則違反が見つかった時とかは修正後ストアドのテストやり直し＞＜；；)
自動テストにしておけばいい。

497 ：

>>496
�dクス。VBAのExplicitに慣れすぎた体にはストアドのこの仕様(?)は堪える。orz

498 ：

質問です
pg_restoreでエラーが出るんですが、原因がわかりません。
CentOS 5.3
PostgreSQL 7.3.6
pg_restore -h localhost -p 5432 -U postgres -v -d "mydb" "/home/root/xxx.backup"
エラーメッセージ
pg_restore: [archiver] unsupported version (1.10) in file header
RedHatでバックアップしたやつなんだけど同じ7.3.6のをバックアップしたのに「unsupported version」ってなんで？？
Windowsで PostgreSQL8.？ を入れてあるやつでバックアップしたんだけどそれが原因？
この場合、無理やりリストアする事はできない？

499 ：

>>495-496
Function作る時にTableがなければerrorでるだろ？

500 ：

>>498
そのエラーメッセージでググると
それっぽいＱ＆Ａ記事が引っかかるよ

501 ：

>>500
ググったんだけどそもそも日本語の結果がほとんどヒットしなくて、
違うバージョンのにリストアする方法しか見つからなかった
因みに諸事情によりdumpのオプション変えて取り直しとかは不可な状況です

502 ：

>>501
訳せよ。

503 ：

>>498
> pg_restore: [archiver] unsupported version (1.10) in file header
>
> RedHatでバックアップしたやつなんだけど同じ7.3.6のをバックアップしたのに「unsupported version」ってなんで？？
> Windowsで PostgreSQL8.？ を入れてあるやつでバックアップしたんだけどそれが原因？
1.10になってるということはPostgreSQL 8.0以降のpg_dumpを使ってしまったみたいだね
> この場合、無理やりリストアする事はできない？
PostgreSQL 8.0以降の版でいったんリストアしてからテキストダンプして古い方に取り込むとか

504 ：

>>499
LANGUAGE SQL の時はね。
LANGUAGE plpgsq lの時は出ない。

505 ：

どっち準拠に従うべき？

506 ：

PostgreSQLだけしか使えない奴って居るの？

507 ：

何の意味があんのその質問

508 ：

全くだな
質問にもそれなりの仕方・手順というものがある
聞かれた方が「何でそんなこと聞くの？」って
目を白黒させるようなものはいただけない

509 ：

いたところで、どうすんのって思うわけで。

510 ：

喧嘩はやめて！(´；ω；)

511 ：

ふたりをを止めて！(´；ω；)

512 ：

サーバーも止めて！

513 ：

私のために争わないで！
ヌルかナルかなんてどっちだっていいじゃない！

514 ：

もぉ、こ〜れ〜い〜じょお〜♪
てか、古いな

515 ：

>>512
（お……Fullか……？）

516 ：

(forever love…？)

517 ：

実行計画が同じなのに実行時間が倍以上違うのは何が原因？
キャッシュなどはすべてクリア済みっす

518 ：

キャッシュのクリアって具体的にどうやってんの？
カーネルが持ってるキャッシュもあるし、OS再起動後に計ってるってこと？
マシンのスペック、postgresql.confは全く一緒なの？

519 ：

>>518
キャッシュクリアの方法ですがOS再起動しています。
以下、作業手順になります。
1.測定
2.OS再起動
3.SQLで使用しているテーブルに対して、VACUUM ANALYZEとREINDEXを実施
4.測定
このとき、1と4の結果で実行計画が同じなのに、処理時間は倍以上あったりします。
ちなみに、4のあとOSを再起動して、
再度、VACUUM ANALYZEとREINDEXを実施後に測定すると、
実行計画や処理時間が1の結果と同じになったりします。（ならないときもあり）
何が原因でここまで不安定になるのでっしょう？

520 ：

同じとか倍とか言うけど、それは10msのオーダーなのか100秒のオーダーなのかわからん。
あと、他のプロセスが忙しかったりはしないのか？

521 ：

あと、vmstat, iostat, ifstat, netstat, dstat, top, htop, sarとかを駆使して、実行環境に違いがないか確認しろ。

522 ：

おっと、そういやOSは何なんだ？

523 ：

>>520
>>521
測定時間は速いときは約30分、遅い時は約1時間です。
測定時裏で動いている各プロセスの動きとかは確認していないので確認してみます。
>>522
OS は CentOS5.6 てす。
あとPostgresSQLのバージョンは 9.2.4.1 です。

524 ：

30分と1時間っていうのは、１つのSQLの１回の実行時間じゃないだろ！
ディスクアクセスの所要時間(待ち時間)の差だけでも３０分ぐらいになるんだろう。

525 ：

一回かもしれないじゃないか(ｶﾞｸｶﾞｸ

526 ：

まさかクライアントとかから同じＳＱＬを何万回も呼び出したりしてるのかしら？
connectして、execして、disconnectしてたりして。

527 ：

うむ、OLTP系とOLAP系の人ではタイムスケールが合わないな

528 ：

なるほど、同じマシンでってことか
まさかとは思うが、autovacuumが動いてて影響してるとか…

529 ：

>>519
1. の方が早いのかな？
当てずっぽうだけど4. の方は、ヒープのヒット率が低くてディスクI/Oが増えてるとか。

530 ：

つか、俺らがそのＰＣの前に行けば、多分５分もあれば原因わかるようなことだろうな。

531 ：

こじれてる初心者質問はどの分野でもそうだけどなｗ

532 ：

久々に笑ったw
ttp://ml.postgresql.jp/pipermail/pgsql-jp/2013-June/016379.html

533 ：

>>532
この人、MLで質問する前に楽天で質問してた
ttp://qanda.rakuten.ne.jp/qa8137892.html
だいじょぶか、この会社

534 ：

>>533
MLに入ってなかったんじゃないの？
2chに慣れてしまっているせいかメールクライアントやMLのスレッド表示はなんか見づらい

535 ：

MLって初心者には敷居が高いしな。

536 ：

9.2でまともに使えるN-gram系の全部検索ライブラリとかあったら教えて欲しい
※標準で入ってるN-gram検索は2文字以下では使い物にならないのでそれ以外で

537 ：

自己解決した
Ludiaで終わってたと思ってたNTTデータがやってくれてました
ありがたやありがたや
これで、MySQLからPostgreSQLに戻ってくることができる

538 ：

>>534
レプリケーションしてるかどうかも確認できないレベルで運用してたってスゴくね？
ド素人がなんでレプリケーション組んだんだろ？
故障してから２４時間、どこから手をつけていいか全然見当つかなかったようだし、
監視ツールも使ってないみたいだし。

539 ：

>>538
世の中のシステム管理者のレベルってそういうのが結構多いよ。
この前、お客さんところ行ってサーバー見たらさ、
RAIDの管理ツールも入ってるのに、SATAのHDDが1台入ってるだけなんだよ。
そこの会社のサーバー数十台全部そういう状態。
担当者は、RAID組んであるはずなのになぁ、、、って言ってたわ。

540 ：

構築する人と運用する人は別だったりするしな。

541 ：

>>539
それ、最初からRAIDになってなかった臭いな。
刑事事件に発展しそうな案件だな。

542 ：

RAIDマネージャー入れたらＯＫと思ってただけなんじゃないの？

543 ：

嘘でしょ

544 ：

ちゃんと入れたほうが金になるから業者もちゃんと入れるだろうに、、、
思いっきり安い見積もりでオプションのHDD入れてないとかかな

545 ：

>>537
pg_bigrm?
標準のginってfastupdateでもやっぱちょっと遅くない？(更新が)
そう言えば9.2でamが追加になってたけど、txtsearchsennaって9.2いけんのけ？

546 ：

発注する時に総務が一番安いモデルにしたとか。
昔勤めていた会社ならやりそうだ。

547 ：

>>545
textsearchsennaはインスコでこける

548 ：

あぁやっぱり。
多分追加になったamを書き足せばいけるだろ。
帰ったらやってみるかな。

549 ：

書いたままクエリを実行する（gccの-O0のような）隠しオプションはないのかな
自分でソース書き換えるしかない？

550 ：

意味不明すぎる。

551 ：

俺も十回読んだが理解できなかった
俺の理解力が足らないのかと少し悩んだ

552 ：

クエリを最適化せずに（書いてある通りに）実行するオプションってことじゃないの

553 ：

join_collapse_limitとかの話？

554 ：

確かそれを1にしても選択と結合の交換などは止められなかったはず

555 ：

"クエリ最適化なし"の定義が分からん

556 ：

コストベースじゃなくてルールベースってことかも。

557 ：

実行計画を自分で決めたいってことか？
でも、「書いたまま」ってのがイミフだな・・・・・・。

558 ：

結合順とか絞り込み順とか、そのままの順番で動いてほしいんじゃないの
結合に関しては()使えば強制できるんだっけ？

559 ：

本人の説明なしにあれこれ推論してもあんま意味ないな

560 ：

大方の見方は一致してるようだけどね

561 ：

説明不足ですみません。
書いたままというのは
select A from R1,R2 where F
みたいな形の式を「R1,R2を結合（直積）して条件Fで選択してAで射影」という素朴な順序で評価する
という意味です。
RDBMSは通常ここから、関係代数式の等価規則を使って演算順序を組み替えるとか、
統計情報をもとにハイパーグラフのリダクションや動的計画法で効率的な順序を決める
といった最適化をして実行計画を作るわけですが、その効果をみる上でもベースとなる
素朴な評価順序での計測ができないかなと思って質問しました。

562 ：

DBMSの比較表でもつくんのかな

563 ：

素朴な順序じゃないだろ。
漢字で表現するなら「愚直な順序」の方が適切だな。

564 ：

というかな、その程度のことなら、ＳＱＬ３回流せば終わりだろ。
�@SELECT R1.*,R2.* FROM R1,R2;
�ASELECT R1.*,R2.* FROM R1,R2 WHERE F;
�BSELECT A FROM R1,R2 WHERE F;
これで561の計測したいことは全部計測できるだろ。

565 ：

結合方法も比較したいかもなぁ。
enable_hashjoin とか使うといいかもね。そこまでの強制力はなかったと思うけど。

566 ：

>>564
これは各段階に常にMaterializeを入れた結果になるから駄目だろ。

567 ：

>>563
select文をパースして最初にできる問い合わせ木の順序と考えると
「素朴」でもいいんじゃない。

568 ：

>>566
>>561は差を知りたいだけなんだろ？

569 ：

pg_hint_plan使えば試したいプランを実行できんじゃないの？
よく知らんけど。

570 ：

そういやそんなんあったな

571 ：

>>561
>>RDBMSは通常ここから、関係代数式の等価規則を使って演算順序を組み替えるとか、
>>統計情報をもとにハイパーグラフのリダクションや動的計画法で効率的な順序を決める
>>といった最適化をして実行計画を作るわけですが、
ポスグレのプランナとオプティマイザは不可分で、最初っからダイナミックプログラミングで
ごりごりプランツリーをつくってくから、「後から最適化」って概念がないんじゃないの。
因みにポスグレはプラン処理の前処理で"1+1"を2にしたり、可能ならサブクエリをJOINにするとかの最適化を行うらしい。
某書籍の受け売り。

572 ：

プランニングの前処理で既にクエリ書き換えちゃうよ
主にやってること

■スカラー表現の簡素化
主に定数たたみ込み(
2 + 2 -> 4
CASE WHEN 2+2 = 4 THEN x+1
ELSE 1/0 END
-> ERROR: division by zero にはなりませんように・・・
はい。なりません。
->x+1です。

■簡単なSQL関数の展開
CREATE FUNCTION incr(int) RETURNS int
AS
'SELECT $1 + 1' LANGUAGE SQL;
SELECT incr(col) FROM table;
-> SELECT col + 1 FROM table;
■ジョイン木の簡素化
・フラット化("pull up")タイプのサブSELECTs 出来るだけ
出来なければ、サブプランを再帰的に生成する。
・UNION ALLをフラット化する、継承木を展開する
・ジョインの長さを削減する(outer join -> inner join)
・IN、EXISTS サブSELECTsをセミジョインに変換する
・非joinを識別する
■簡単なviewのフラット化
CREATE VIEW v AS
SELECT a, b+c AS d FROM t WHERE x > 0;
SELECT v.a, v.d FROM v WHERE v.a = 42;

Rewriterによる生成：
SELECT v.a, v.d FROM
(SELECT a, b+c AS d FROM t WHERE x > 0) v
WHERE v.a = 42;

サブSELECTフラット化による生成：
SELECT t.a, t.b+t.c FROM t
WHERE t.x > 0 AND t.a =42;

573 ：

間抜けな質問がないと、盛り上がらんな。

574 ：

>>541
刑事事件じゃなくて、民事だろ！
って、おもってから、数秒後・・・あぁ、なるほど、刑事事件か。と納得した。

575 ：

単に管理ソフト入れたらRAIDになると勘違いしてただけだろ。

576 ：

すみません。初心者です。
update文で教えてください。
顧客情報のテーブル→t_client
注文内容のテーブル→t_orderがあります。
注文内容と顧客情報を合体させて、
顧客情報にカートIDを入れたいです。
ご教授よろしくお願いします。

577 ：

これは酷いw

578 ：

>>576
SQLの基礎さえできていないようだけど
どういう経緯でそんなことをやる羽目になったの？
もし業務でやらされているのならば
明日朝一番にギブアップ報告しろと言いたくなるレベル。

579 ：

これはレスした方が負けだろ。

580 ：

メアドといい、怪し過ぎる
レスしたら負けだ

581 ：

up pu

582 ：

>>576
あなたが設計したの？
他の人が設計したんじゃなきゃもう一度勉強してやり直した方がいいよ

583 ：

>>576
それならテーブル構成ぐらい晒せや

584 ：

過去に構築したPostgreSQL 7.4.16がRedhatで稼働しています。
この度、ハードウェア更新することになり、Linuxもバージョンアップします。
その際に過去のDBを移行するのですが、7.4.xxをインストールするのが
最も作業量ミニマムでしょうか？

585 ：

まあそうかもね
ダンプ→りストアでだいたい済むけど
7->8はキャストしてないと通らなかったりするからなあ
って同じサーバに複数のバージョンのpostgreSQL入れて試してみりゃいいじゃん

586 ：

新しいハードにESXi入れて、VMWare Converterで古いハードをP2Vするのが
一番作業量が少ないと思う。

587 ：

7 を入れるなんて、恐ろしいからやめてくれ。
こないだ重大な脆弱性に対する緊急アプデがあったばかりで
7とかはアプデ対象外だというに。

588 ：

脆弱性なんて、他の手段でなんとかなるだろ。

589 ：

表にそのまま出すケースのが少ないしな

590 ：

新しいものに移行することに労力を割くか、
古いものを運用し続けることに労力を割くか、

591 ：

ま、ポート変えりゃいろんなバージョン同時にいくつも動かせるんだから
検証しながらやればいいよなあ

592 ：

>>591
アホなＨ社に全プログラムをタダで再検証させられたぜよ。
Ｈ社のＤＢのスペシャリストが本番と違うバージョンでテストしてたくせに。

593 ：

Hって国産DBやってるとこ？
あそこのオープンソース系の連中、腐ってるだろ
なんのアウトプットも無い

594 ：

>>593
オープンソース？
そんなんやってたっけ？
昔、S○ がちょっとやってたぐらいしか知らない
オープンアーキテクチャ (と、彼らがほざいてる) のことなら、同意

595 ：

この辺じゃないの？
http://www.hitachi.co.jp/products/it/linux/opensource/index.html
SystemTapはお世話になった

596 ：

>>595
なるほど、それなりにやってるんだな。

597 ：

やるのは構わんが自分とこのミスを他所に押し付けるのが困る。

598 ：

責任転嫁する為に外注するんじゃないの？

599 ：

まあそのために金出してるんだしなｗ

600 ：

つまり、まともな客じゃねぇんだな。

601 ：

ちょっとしたソーシャルゲームをつくろうとおもっています。
1000ビットくらいあるフラグのアレイを bit varying型 で格納するべきか、
それとも1フラグ1レコードで記憶すべきか・・・。
bit varying の nビット目が 0か1か調べたり、0や1を直接書き込む効率的な関数ってありましたっけ？

602 ：

両方試した方が早いよ。

603 ：

>>601
http://www.postgresql.jp/document/9.1/html/functions-bitstring.html
> &、|、#のビット文字列オペランドは同一長でなければなりません。
という記述を見てまずいかと思ったけど、キャストで解決できるようだ。
効率的な関数とやらはよく調べてないのでわかんないけど、一般的なフラグ処理でいいんじゃないのかな。
それでも必要だとおもい、調べても見つからないなら作ればいいかと。

604 ：

>>602 なるほど、もっともです。ありがとう。
>>603 どうも無さそうなので、PL/pgSQLの関数を作ってみました。
ただ、自分の方法はすごく頭の悪い方法かもしれないです。
5ビット目とか6ビット目ならシフトで気にならないですが、
800ビット目とか900ビット目とかになると、
その回数シフトさせるオーバーヘッドが気持ち悪いです。
もっとも、EXPLAIN ANALYSE で見るボトルネックはもっと他にあるようで、
5ビットも900ビットも大差なかったです。
そして、１フィールドに全フラグを押し込める方式も、フラグごとに１レコード用意する方式も、
全体のデータが少ない現在の試験環境では処理コストそのものに大差ないようです。
というわけで、今後は
・複数のフラグを（たとえば１０個や２０個を）まとめて処理する状況が頻発するのか
・フラグごとに集計する必要があるのか
・１レコード１フラグにしてメモリーにのりきるのかどうか
このあたりから熟考してみます。>>602-603 ありがとう。

605 ：

.NETサポートまだですか

606 ：

Npgsqlとかじゃなくて公式でってこと？

607 ：

はじめまして。よろしければ、何点かお教えいただきたいことがございます。
イレギュラーな質問が多くて恐縮なのですが。

1/3 64bitサーバで32bit版のPostgreSQLは動作するのか
具体的には、x86_64のサーバ(CentOS5)で、32bit版のPostgreSQL8.2のRPMは正
常に動作できるのでしょうか？
x86_64の仮想サーバ(CentOS5)で試したところ、32bit版のPostgreSQL8.2の
postgresql, postgresql-lib, postgresql-server
をインストール、動作させることができました。
どうやら動作自体はするもののようです。
ただ、原理的に正常に動くものなのか、どなたかお教えいただけないでしょう
か。

608 ：

2/3 PostgreSQLの8.2と9.1のRPM版は共存できるか。
具体的には、32bit版の8.2と、64bit版の9.1のです。
RPMで複数バージョンのPostgreSQLをインストールしてみよう ? Let's Postgres
http://lets.postgresql.jp/documents/tutorial/new_rpm
この記事は9.0以降のRPM同士についてのようですが、インストール先ディレクトリが
/usr/pgsql-<メジャーバージョン>
となっているなら、それより前のバージョンのRPMもひとつは共存できるかと思い
試してみました。
先に8.2(32bit)をインストールした環境に、9.1(64bit)の
postgresql, postgresql-lib, postgresql-server
のRPMをインストールすると、
> エラー: 依存性の欠如:
> postgresql < 7.4 は postgresql-server-8.2.22-1PGDG.rhel5.i386 と競合します。
というエラーが出ました。
そこで、 --force --nodeps というオプションをつけるとインストールでき、
9.1のポート番号を変えると、8.2, 9.1のどちらも動作しました。
update-alternatives が設定されるので /usr/bin/psql などは9.1系になって
しまうかと思いましたが、実際には8.2系のままでした。
rpm -ql でファイルのインストール先を確認したところ、どれもかぶってはい
ませんでした。
ただ、これもかなり変則的な使い方のようなので、原理的に動作するものなのか
お伺いしたいのです。

609 ：

3/3 OpenJDKを使う場合、RPMファイル postgresql-jdbc のインストールは必要か
これだけは変則的でない質問かもしれません。
postgresql-jdbc の内容を見たところ、JDBCのjarファイルの他は、GCJのライ
ブラリだけのようでした。これならこのRPMはインストールする必要がなく、
Download
http://jdbc.postgresql.org/download.html
からJARファイルを取得するだけで良いのではないかと思うのですが、いかがで
しょうか？
実は、8.2(32bit)のpostgresql-jdbcのインストールに失敗しました。
> エラー: 依存性の欠如:
> libgcj_bc.so.1 は postgresql-jdbc-8.2.512-1PGDG.rhel5.i386 に必要とされています
32bit版のgcjとの依存関係があったのです。使わないGCJ(32bit)をサー
バに入れずに済ませたくて、質問させて頂きました。

以上です。変則的な質問が多くて恐縮ですが、どうかよろしくお願いいたします。

610 ：

質問するまでも無いことまで質問してるな。

611 ：

9.4出たら起こして

612 ：

9.3はいいのかw

613 ：

>>607 いいんじゃない？
>>608 いや、ポート番号を変えるのが常道であって、それで正解だと思うが？

614 ：

マテビューってすごく待ってたんだけどよく考えたら使い道無かった。
自動更新とか無いと一時テーブルと何も変わらんよなあ…
マテビュー(ポスグレの)リフレッシュするときって排他ロック掛かるよね？

615 ：

うちはランキングのテーブルとかに使おうかなと考えている。
とはいっても、現時点で既に cronで定期的に 実表にランキングを書き出しているから
新たにマテビューをつかうメリットなんて思いつかないが。
それはそうと、
ttp://www.slideshare.net/hadoopxnttdata/postgre-sql93-24136770
このスライドいいね。 9.3 とか 9.4 がよくわかった。

616 ：

>>613
ご回答ありがとうございます。
そもそも自分は、64bitサーバで32bitバイナリが動くということ自体、知りま
せんでした。
64bit環境での32bitプロセスの動作 - Linuxカーネルメモ
http://wiki.bit-hive.com/linuxkernelmemo/pg/64bit%B4%C4%B6%AD%A4%C7%A4%CE32bit%A5%D7%A5%ED%A5%BB%A5%B9%A4%CE%C6%B0%BA%EE
動かない場合はないのか、PostgreSQLは大丈夫なのか、お伺いしたかったので
す。
8.2(32bit)と9.1(64bit)でインストール先のファイルがかぶらないことは確認
できたのですが、ポートの他に競合するものがないか不安で、質問させていた
だきました。
--
お詫びしますが、実は >>607-609 はマルチポストです。申し訳ありません。
先に7/15(月)にpgsql-jp に加入、投稿させていただいたのですが、「 メール
に不審なヘッダがあります」とのことで「リスト司会者のチェックのために投
稿が保留されました。」という状態になってしまいました。
3日待っても進展がなかったので、こちらのスレッドに同じ内容を書き込ませ
ていただいた次第です。
ちなみに現在も進展がありません。どうなってしまったんだろう…。

617 ：

答えるまでも無いと思われてるか、ここで質問されてるからいいやと思われたのか。

618 ：

9.2のMVって、一体どういう風に使われるのを想定してるんだろうか？
triggerなんかで更新が必要なら、実表とそう変わらん気がする。

619 ：

参照の高速化じゃない？
今のところ自動リフレッシュがなさそうに見えるので用途は限定されるかも

620 ：

正直、９．１で十分だと思う。

621 ：

インデックスオンリースキャンはガチ

622 ：

正直8.1で十分だと思う
そうほざいてた時期が俺にもありました

623 ：

ポスグレってオラクルの何パーセントくらい凄いの？

624 ：

それを知ってどうしたいのかにもよるけど、たぶん3%ぐらいって答えておくのがいいパターンだと思う

625 ：

そっかー(´・ェ・)ちなみにMySQLはポスグレの何%ぐらい凄いのー？

626 ：

まちがったー(´・ェ・)MySQLはオラクルの何%ぐらい凄いのー？

627 ：

過疎ってると思ったら、突然馬鹿が二人現れたな

628 ：

(´・ェ・)

629 ：

>>627
一人はぼくだとして(´・ェ・)もう一人は誰ー？

630 ：

>>629
もう一人もキミだよ。

631 ：

（・3・）アルェー

632 ：

>>630
なんだー(´・ェ・)ぼくは一人じゃなかったのかー

633 ：

話題は？

634 ：

最近ちょっと太った。

635 ：

今ままでOracle、SQL Serverをやってきたんだけど、日本語DBだったんだ
だから、ポスグレはちゃんと英単語を使いたいと思ってる
項目名どうやって決定してるよ？

636 ：

日本語で問題ないよ。テーブル名はさすがに英語にしてるけど。

637 ：

全て日本語で問題なし
ソフトが対応していないならともかく
日本人なのにわざわざ英語を使う必要はない

638 ：

>>636
さすがに、ってどういう意味で言ってるの？
マルチバイトサポートしてるだろ？

639 ：

>>638
カラム名だけを日本語にするのとテーブル名も日本語にするのでは、心理的障壁の高さが違うんでしょう。

640 ：

すみません。
slony-iの導入について、教えていただけませんでしょうか。
Windows2008R2にPostgreSQL(32bit) 9.0.13をインストールし、
さらに、スタックビルダを使ってslony-I 2.0.7-1をインストールしました。
C:\Program Files (x86)\PostgreSQL\9.0\bin
内に　slon.exeが追加されたのはいいのですが、
コマンドプロンプトでslon.exeをたたくと、
「コンピューターに MSVCR90.dll がないため、プログラムを開始できません。
この問題を解決するには、プログラムを再インストールしてみてください。」
というエラーメッセージが表示されます。
※VC++ランタイムは、2003〜2013まで入っています。
そこで、参照がうまくいっていないのだと思い、
システムフォルダから「MSVCR90.dll」を上記binフォルダに入れてみましたところ、
下記のようなエラーとなりました。
「Microsoft Visual C++ Runtime Library
Runtime Error!
Program: C:\Program Files (x86)\PostgreSQL\9.0\bin\slon.exe
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.」
導入方法や検証方法に誤りがあれば、ご指摘いただきたく思います。
よろしくお願いします。

641 ：

http://www.microsoft.com/ja-jp/download/details.aspx?id=29
ランタイム入れなおしたら？

642 ：

Windows自体が 64bit で、32bit の dll 持ってないとかじゃないの？
システムフォルダからコピーしてくる、ってのは割と悪手な気がする…

643 ：

ところで２ちゃんねるが閉鎖された場合の避難所ってどうなってるの？
オープンソースなPostgreSQLなら、やっぱ、おーぷん２ちゃんねる？

644 ：

>641
何度も入れなおしてみましたが、結果は同じでした。
>642
Winは64bitです。
ただ、641が張ってくれてるリンクがx86用だから、
それをインストールしたら、32bitのdllを持ってるって事ですよね...？

645 ：

Winが64bitなのは
＞C:\Program Files (x86)
これでわかるって。
実行してるものは32なのか64なのか

646 ：

>645
PostgreSQLは32bitです。
slonも、スタックビルだでインストールしたので、32bitだと思います。

一応64bit用の「msvcr90.dll」もbinフォルダに入れて見ましたが、
以下のようなエラーが出ました。
※640のエラーはx86の「msvcr90.dll」を入れた際のエラーです。
「アプリケーションを正しく起動できませんでした (0xc000007b)。
[OK] をクリックしてアプリケーションを閉じてください。 」
ランタイムエラーが出てる->DLLを読み込めてはいる？
だと思うので、Slonも32bit用だと思います。

勘違いしてて、レスにあっていない返答になってたらすみません。

647 ：

Dependency Walker で見てみたらどうなるかなあ、MSVCRT90だけかな？

648 ：

おっと、MSVCR90か

649 ：

>647
Dependency Walkerで見てみると、
「LIBEAY32.DLL」も足りないといわれたので、
http://slproweb.com/products/Win32OpenSSL.html
から、「Win32 OpenSSL v1.0.1e」と「Win64 OpenSSL v1.0.1e」を
インストールしてみようとしましたが、
両方とも次のエラーが出ました。
「The Windows OpenSSL Installation Project setup has detected that the following critical component is missing:
Microsoft Visual C++ 2008 Redistributables」
どうにもこうにもVC++2008ランタイムが、正しくインストールされていないようです。
もう少し試行錯誤してみます。

650 ：

http://www7a.biglobe.ne.jp/~kasachan/VCrt_Check.html
これの
※VC のランタイムチェック の補足
かなあ、サーバはあまりいじくりまわさないからなあ。

651 ：

話題は？

652 ：

$ postgres --version
見せてほしい。

653 ：

7.3.4

654 ：

>>653
ちょっと安心した
postgres (PostgreSQL) 8.4.12

655 ：

1.2.3

656 ：

Lotusかよ

657 ：

9.2.4

658 ：

Porscheかよ

659 ：

２５２

660 ：

>>656さんの体臭からノネナールを検出

661 ：

PostgreSQL 9.3 released!
http://www.postgresql.org/about/news/1481/

662 ：

ウリは？

663 ：

Windowsに先んじてversion 9.3になりました。

664 ：

ウリって売りかｗ
9.3 はビューに直接UPDATEかけられるとか

665 ：

SUMしたVIEWにもUPDATEかけれるのか？

666 ：

ttps://wiki.postgresql.org/wiki/What's_new_in_PostgreSQL_9.3#Updatable_Views
Simple views can now be updated in the same way as regular tables.
The view can only reference one table (or another updatable view)
and must not contain more complex operators, join types etc.

667 ：

>>666
ようやくOracle 8i並みになったってことか？

668 ：

>>306
起きろ

669 ：

pgpool2使ってんだけどさ、障害時はもちろん、復旧時も完全にノンストップってのは出来るもんなの？
postgre鯖とpgpool2鯖はそれぞれ複数台づつあって、全部同時に壊れる事は無いとして。
pgpool2が1台にpostgre複数台ならまだ少し情報あるけど
pgpool2も複数台の構成は全然情報見つからない

670 ：

イミフ。ハートビートがあるじゃん。

671 ：

PostgreSQLは、そのへんのtoolが不安定というか、雑魚っぽいのが何種類もあるのが
ネガティブイメージなんだよな。
Replicationみたいに、どれかを本体に組み込んで欲しいよな。

672 ：

なんでピジプーを本体のフロントエンドに入れないかねぇ。
インストール時に選択できるようにすればいいのに。

673 ：

そんな怪しいプログラムが好きなのは、日本人のなかのごく一部だからなんじゃないの？
あの会社や、その会社の関係者だけだろ。

674 ：

あの会社だけ〜とかほんま性格悪いわ〜、引くわ〜。
ど〜せゾウさん関係にたいした知識もなく言ってんだろ〜？老害だわ〜。

675 ：

みんなひどいわ

676 ：

データベーサー同士仲良くやりたまえ

677 ：

ダースベイダー？

678 ：

こー　こー　こー　

679 ：

postgresqlのGIN検索が２文字だとインデックス使ってくれない問題って治ってます？
textsearch-ja使ってるんだけど２文字検索遅すぎなんだがぁ

680 ：

NoSQL使わずこれ使う理由ある？

681 ：

基本的に目指す方向性が違うだろ
用途によるとしかいえない

682 ：

すまん初めて使ってみるんだデーターベース
オンラインゲーを作りたいんだけど、保存するのはユーザー情報と各種ゲーム内パラメーター
Postgresじゃ厳しいよね？

683 ：

うん、かなり厳しい。


Postgres じゃなくて、君の方が

684 ：

KVSで済むならまあそれでいいんじゃない？
実はデータベースが本体で、サーバの提供する機能とか
ゲームクライアントはそのデータベースのデータを書き換える
補助ツールにすぎない、と考えることもできる。

685 ：

>>684
おーまさにそんな感じだ
とりあえずmongodbでやってみるよ

686 ：

>>682
バンバン稼ぐつもりなら、俺なら最初からオラクル使っとくな。
最初の内はXE使って、順調に行けばAmazonのRDSとかを使う前提で。
稼げるかどうかわからないなら、PostgreSQLにしとく。

687 ：

>>686
結局SQL推しか

688 ：2013/09/23

SQLは使いこなせる人にとっては実に便利だからな。
使いこなせねー奴は、流行りの言語やツール使っとけば良いよ。