PostgreSQL Part.10
レス数が1000を超えています。これ以上書き込みはできません。
0001NAME IS NULL
2014/02/26(水) 03:35:14.92ID:???●関連サイト
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.9
http://toro.2ch.net/test/read.cgi/db/1338040695/
0002NAME IS NULL
2014/02/26(水) 03:36:44.86ID:???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 Part.9
http://toro.2ch.net/test/read.cgi/db/1338040695/
●関連過去スレ
■ 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/
0003NAME IS NULL
2014/02/26(水) 03:39:42.92ID:???0004NAME IS NULL
2014/02/26(水) 19:14:46.24ID:???早速質問なんですが、ビューのメリットって具体的にはどんなところがありますか？
これまでビューを多用してアプリを組んでいたのですが、元になるテーブルやビューを変更するたびに、依存性の問題で色々と苦労することのほうが多かったです。
それで今では新しいアプリを制作する段では、なるべくビューを使わずにアプリ内で全て記述するようにしています。
（特に結合ビュー）
速度的なメリットみたいなものはビューにはありませんよね？
0005NAME IS NULL
2014/02/26(水) 21:17:41.01ID:???・何度も使う場合に記述が簡潔になる
・db側で一括管理することによって呼び出しが散らばっているアプリ側を触らなくてもよくなる
他にあるかな
アプリ側でちゃんと管理出来てれば特に必要ないね
0006NAME IS NULL
2014/02/26(水) 22:09:22.53ID:???あるいは、次の2つにはどのような違いがあるでしょうか。
create index foo_idx on table123(foo);
create index foo_idx on table123(foo) where foo is not null;
postgres 9.3 です。
0007NAME IS NULL
2014/02/27(木) 00:01:42.15ID:???変更が少なくない頻度で発生するシステムだとやっぱり面倒だという印象。
マテリアライズドビューなら速度的なメリットがある
更新可能VIEWも限定的な場面でメリットがあるかも
>>6
つけたほうがいい。抽出時に xxx is not null を使うなら。(きっと使うだろうけど)
0008NAME IS NULL
2014/02/27(木) 05:44:17.07ID:???でコンヒグしてますがなにか。
0009NAME IS NULL
2014/02/27(木) 08:59:18.43ID:???今まででも普通にテーブルをcreate asで作るのと変わらないという…
今後自動更新がつく予定はあるのかな。
0010NAME IS NULL
2014/02/27(木) 17:10:33.72ID:???>つけたほうがいい。抽出時に xxx is not null を使うなら。(きっと使うだろうけど)
ありがとうございます。つけることにします。
0011NAME IS NULL
2014/03/11(火) 21:46:02.30ID:???0012NAME IS NULL
2014/03/16(日) 22:39:02.96ID:???http://www.postgresql.jp/document/9.3/html/libpq-async.html
を見ているのですが、これであってますでしょうか。
PGsendQuery(conn, "select * from table");
PGconsumeInput(conn);
while (PGisBusy(conn)) {
// wait
}
while ((result = PGgetResult(conn)) != null) {
// print result
}
サンプルコードがないのでつらいです。
0013NAME IS NULL
2014/03/17(月) 01:02:50.29ID:???自分は実際に非同期クエリを試したことが無いので、間違っていたらゴメン
ドキュメントに書かれているように、
PQsendQuery でリクエストを送信後にレスポンスの受信を待ち受けるには、
一般には select() または poll() システムコールを使う
そしてレスポンスが到着すると上記システムコールがリターンするから、
すかさずPQconsumeInputで吸い取り、PGgetResultでレスポンスを得る
これが「イベント駆動方式」の基本的な考え方であり、
TCP/IPソケットを使うサーバアプリ設計において、
スレッドを使わずに複数コネクションを並行処理する手法として、よく知られている
PQisBusyとタイマー待ちを用いたいわゆる「ビジー＆ウエイト方式」でも
動作するけど、イベント駆動方式と比べると性能で劣るため、
イベント駆動方式が採用できない場合の代替案になる
0014NAME IS NULL
2014/03/17(月) 01:18:55.15ID:???select()やpoll()ってサーバプログラムが使うと教わったんですが、必ずしもそうではないんですね。
PGconnオブジェクトからソケットって取り出せるんでしょうか。やっぱりサンプルがほしいです。
0015NAME IS NULL
2014/03/17(月) 07:37:09.05ID:???> PGconnオブジェクトからソケットって取り出せるんでしょうか。
PQsocket じゃダメなん？
http://www.postgresql.jp/document/9.3/html/libpq-status.html
0016NAME IS NULL
2014/03/17(月) 15:37:46.67ID:???サンプルがないと分からないというけど、非同期処理に慣れてないだけって気がする。
まずは伝統的なチャットプログラムでも作ってみてはいかがか。
がんばれがんばれ！
001713
2014/03/17(月) 21:27:42.28ID:???公式ドキュメントでは、select() の使い方が以下のサンプルで示されている
・例 31-2. libpq サンプルプログラム 2「非同期通知インタフェースの試験」
http://www.postgresql.jp/document/9.3/html/libpq-example.html
ただし残念ながら、これは(非同期レスポンス受信処理ではなく)非同期通知処理の
サンプルだから、PQnotifies を PQgetResult へ置き換えて読む必要がある
もし英語が読めるのであれば、以下のQ&Aにある Alex Hunsaker氏のレスと
それに続く議論が、非同期リクエスト/レスポンス処理に関する直接的な参考になる
・Should PQconsumeInput/PQisBusy be expensive to use?
http://postgresql.1045698.n5.nabble.com/Should-PQconsumeInput-PQisBusy-be-expensive-to-use-td3239495.html
> You really want to select() or equivalent here... This basically is a
> busy loop using 100% cpu; neither PQconsumeInput or PQisBusy do any
> kind of sleeping...
>
> Something like:
> fd_set read_mask;
> int sock = PQsocket(st->con);
> FD_ZERO(&read_mask);
> FD_SET(sock, &read_mask);
>
> while(1)
> {
> struct timeval tv = {5, 0};
> select(sock+1, &read_mask, NULL, NULL, &tv);
> PQconsumeInput(self.db)
> if (!PQisBusy(self.db))
> break;
> }
>
> or something...
0018NAME IS NULL
2014/03/17(月) 22:56:25.71ID:???> これが「イベント駆動方式」の基本的な考え方であり、
> TCP/IPソケットを使うサーバアプリ設計において、
> スレッドを使わずに複数コネクションを並行処理する手法として、よく知られている
ねぇ、これと、そのコードはマッチしないことは分かってる？
001913
2014/03/17(月) 23:24:18.94ID:???まず>>12,14はソケットやselectシステムコールの使い方を知らず、
それらとlibpqライブラリ関数とを組み合わせたプログラミングの
イメージを持てないようだったから、それに最も近いサンプルを紹介しただけだよ
>>17のコードはレスポンスの到着イベント待ちと受信の処理しか実装されていないけど、
イベント駆動方式のPostgreプログラミングにとって最初の一歩になるはずだ
もしも>>18が>>17のコードを見て、これがイベント駆動方式ベースのサーバアプリ設計の
すべてを表現したものだと判断したのなら、頭がおかしいと言わざるを得ない
0020NAME IS NULL
2014/03/17(月) 23:44:50.62ID:???いやいや、突っ込みどころが多すぎるんだって。
>>13で書いた日本語と、>>17で引っ張ってきたコードのタイプが異なることで
初心者にどれほどの混乱をもたらすか考えてみなよ。
> PQnotifies を PQgetResult へ置き換えて読む必要がある
これも。単にそうするとブロッキングする場合があるのは分かる？
置き換えて読んだらアウトなんだよ。
0021NAME IS NULL
2014/03/17(月) 23:47:44.24ID:???> {
> struct timeval tv = {5, 0};
> select(sock+1, &read_mask, NULL, NULL, &tv);
> PQconsumeInput(self.db)
> if (!PQisBusy(self.db))
> break;
> }
これを使って
> スレッドを使わずに複数コネクションを並行処理する
を満たしてくれよ。
002213
2014/03/17(月) 23:52:07.93ID:???自分に噛み付くのはかまわないんだけど、
その労力を>>12,13の助けになる情報の提供に
費やしたほうが、スレにとっては有益な議論になると思う
>>20であれば、初心者が混乱しないPostgreの
非同期プログラミングについて、
サンプルを交えて分かりやすく解説できるのではないのかな？
002313
2014/03/17(月) 23:53:08.51ID:???>もしも>>18が>>17のコードを見て、これがイベント駆動方式ベースのサーバアプリ設計の
>すべてを表現したものだと判断したのなら、頭がおかしいと言わざるを得ない
0024NAME IS NULL
2014/03/17(月) 23:57:45.16ID:???>>16を書いたよ。それが近道だと思ったから。
0025NAME IS NULL
2014/03/18(火) 16:57:58.87ID:???相手に頭おかしいとか言うなよ
0026NAME IS NULL
2014/03/18(火) 20:31:29.89ID:???DB設計スレにも似たような面倒な人がいる
0027NAME IS NULL
2014/03/19(水) 08:00:48.75ID:???0028NAME IS NULL
2014/03/20(木) 23:58:34.63ID:???http://www.postgresql.org/about/news/1511/
0029NAME IS NULL
2014/03/25(火) 12:14:00.99ID:???json型サポートされてるみたいだけど、実際に使ってる人いる?
今はmysqlとmongoなんだけど、可能ならpg一つで運用したい。。
0030NAME IS NULL
2014/03/25(火) 13:03:38.37ID:???0031NAME IS NULL
2014/04/05(土) 01:17:58.75ID:???Oracleに合わせてユーザ名＝デフォルトスキーマ名にしようかと思ってます
0032NAME IS NULL
2014/04/05(土) 09:35:51.13ID:???そこで無料のデータベースを検討しています。
ExcelをGUIの窓口にして、PostgeSQLに仕事をさせることは可能ですか？
両者を連携させる技術を学ぶには、どういうキーワードでググればいいでしょうか。
0033NAME IS NULL
2014/04/05(土) 10:03:36.00ID:???http://blog.goo.ne.jp/xmldtp/e/06a83bd11cb9ceb02ace5d0130d533d8
アクセスの方法はExcelVBAからAccessデータベースにアクセスするのと変わらないはず。
http://ateitexe.com/access-database1/
0034NAME IS NULL
2014/04/05(土) 11:07:18.40ID:???情報サンクスです。勉強します。
0035NAME IS NULL
2014/04/05(土) 12:49:11.13ID:???なんか凄い違和感がある
0036NAME IS NULL
2014/04/05(土) 12:51:19.14ID:???「はず」ではなく、問題なくできます。
ただしPostgres側の設定をしないといけないので（使えるように）、Accessの知識だけではちょっと難しいかもですね
0037NAME IS NULL
2014/04/05(土) 14:09:41.17ID:???ってpgスレで言うことでもないか
0038NAME IS NULL
2014/04/05(土) 18:25:13.90ID:bZkzKMAB俺は特に違和感ないな。
俺の記憶が正しければ、元々ingresっていうDBがあって（SQL標準化よりかなり前）、
その後継としてpostgresが開発されて（後継だからingresの"in"を"post"に変えた）
それをSQL対応させた物がPostgresQLだから、"post-gres"がpgと略されるのは自然
0039NAME IS NULL
2014/04/05(土) 22:33:55.06ID:???へぇーへぇーへぇー
ついでに質問ですが
libpqの関数や型のプレフィックスに
PG*で始まるものとPQ*で始まるものがあるのはなんでですか？
0040NAME IS NULL
2014/04/06(日) 00:16:06.74ID:???頭の悪いレスだな
0041NAME IS NULL
2014/04/09(水) 15:07:49.31ID:???普通に、Postgresだろ？
0042NAME IS NULL
2014/04/09(水) 15:08:45.82ID:???0043NAME IS NULL
2014/04/09(水) 15:09:38.60ID:???0044NAME IS NULL
2014/04/09(水) 15:24:57.50ID:???0045NAME IS NULL
2014/04/09(水) 15:38:03.26ID:???0046NAME IS NULL
2014/04/09(水) 15:38:58.23ID:???俺はpgAdmin使うけどね。そういう話だよ。
0047NAME IS NULL
2014/04/09(水) 16:29:34.84ID:???そういう話じゃねーだろ、あほ
0048NAME IS NULL
2014/04/09(水) 16:36:37.56ID:???え
mかmyにしかならん
0049NAME IS NULL
2014/04/09(水) 16:50:02.12ID:???まさかｗ
0050NAME IS NULL
2014/04/09(水) 17:01:57.18ID:???ことかと思った。歴史を知らないと「Postgre + SQL」って切れるように見えるから、
なぜ「ps」にならないのかっていう質問かと勘違いした。
会話とかでPostgresのことを「ぴーじー」って言うかどうかっていう点だったら、ノーだな･･･
0051NAME IS NULL
2014/04/09(水) 17:24:05.19ID:???そんなやつはいないだろうと思っていたんだけど、その観点で話してる人がいるようで、驚いてるところ。
> 歴史を知らないと「Postgre + SQL」って切れるように見えるから、
ポスグレという言い方をする人もいるね。
歴史を知らないからか、言いやすいからか、はたまた両方なのかは不明。
0052NAME IS NULL
2014/04/09(水) 17:32:05.90ID:???若者：PG=ペア画
あほ：PG=PostgreSQL
0053NAME IS NULL
2014/04/09(水) 17:35:59.73ID:???ポストグレスを短く言いやすく言ってるもんだと思ってた
post-ingresよね。postgresになって、postgresqlになった
MS SQL Serverとは兄弟ってことさ
0054NAME IS NULL
2014/04/09(水) 17:43:18.56ID:???0055NAME IS NULL
2014/04/10(木) 03:29:52.78ID:???0056NAME IS NULL
2014/04/10(木) 09:47:44.48ID:???途中で切られた感があるよねｗ
0057NAME IS NULL
2014/04/11(金) 03:22:23.19ID:???データ量がすごい増えたので、次はOracleって・・・・
そんな話しって普通？
確かに、遅い処理の所もあるけど、Oracleって高いしな
最近のバージョン同士で速度比較とかした人いないですよね？
0058NAME IS NULL
2014/04/11(金) 07:19:26.52ID:???0059NAME IS NULL
2014/04/11(金) 09:18:34.86ID:???あると思います
0060NAME IS NULL
2014/04/11(金) 13:16:57.83ID:???まあ、なんかあった時の言い訳保険として入っているが (w
0061NAME IS NULL
2014/04/12(土) 13:35:17.10ID:???postgres (PostgreSQL) 9.0.13
Mac OS X 10.7.5
ですが、
psql で ヒストリーだけが文字化けします(他の操作は問題無いです)。
psql の encoding は UTF8 で、端末も環境も同様に全て UTF8です。
.psql_history に書き込まれている文字コードを nkf で確認したところ、
ASCII となっていました。
何か設定が必要なのでしょうか？
ちなみに私の他の Linux 環境ではこの問題は起こってません。
0062NAME IS NULL
2014/04/16(水) 15:58:36.74ID:???ヒストリーを閲覧しようとすると、
/dev/tty がどうこうってエラーが出るとか
まだ解決してないみたい
Macで業務とかに本格的にPostgres使ってるユーザーってそんなに少ない？
0063NAME IS NULL
2014/04/16(水) 16:05:45.53ID:???0064NAME IS NULL
2014/04/16(水) 16:37:46.90ID:???MacのターミナルまたはiTerm2とかからsshでLinuxサーバやMac上の仮想Linuxに接続してpsqlを使った場合は何も問題がないのでMacの端末側の問題では無いとは思ってます。
実機はLinuxなので、これまで開発環境はMac上の仮想Linuxでしたが、Postgresの為だけに仮想OSを使うのも無駄かなって思ってサーバ版のOSXで標準インストールされるPostgresを使ってみました。
DBの動作自体はに何も問題ないです。
端末側でユーザーとのやり取りをするpsqlだけが上手くいきません。
0065NAME IS NULL
2014/04/16(水) 16:40:54.28ID:???ascii文字だけしか無ければUTF-8とASCIIは何も違いが無いのでASCIIと判定されるよ。
0066NAME IS NULL
2014/04/16(水) 16:43:19.63ID:???たとえば、バクスラとかもいちいちエンコードされて出力されます
0067NAME IS NULL
2014/04/16(水) 16:45:14.57ID:???0068NAME IS NULL
2014/04/16(水) 16:55:54.22ID:???で、そのascii文字であるところのバックスラッシュがどうエンコードされるの？
0069NAME IS NULL
2014/04/16(水) 16:59:43.05ID:???Macのreadlineのバグ修正を探すか、libeditも使えるみたいだから置き換えて自前でビルドしてみては？
0070NAME IS NULL
2014/04/16(水) 17:02:44.29ID:???まだ.psql_historyにマルチバイト文字が含まれているかどうかを確認できてない。
バグだと判断するには時期尚早。
0071NAME IS NULL
2014/04/16(水) 18:01:37.31ID:???遅くなりました、66です。
バックスラッシュが8進で134(10進では92ですね)、
スペースは8進で040(同じく10進表現では32)として、
.psql_history に書き込まれています。
0072NAME IS NULL
2014/04/16(水) 18:06:06.16ID:???62です。
そういえば、Postgresとは無関係ですが、OSXでreadline関連の不具合(?)情報を見かけたことが有ります。
具体的な内容は忘れてしまいましたが。
0073NAME IS NULL
2014/04/16(水) 18:09:14.78ID:???62=69です。
お世話になります。
マルチバイト文字も全て8進表現のASCIIで書き込まれています。
0074NAME IS NULL
2014/04/16(水) 18:10:07.71ID:???×62=69です。
◯62=66です。
失礼しました
0075NAME IS NULL
2014/04/16(水) 18:38:11.33ID:???0076NAME IS NULL
2014/04/16(水) 18:42:30.18ID:???readline 外すとhistoryできないね。
0077NAME IS NULL
2014/04/16(水) 19:14:48.83ID:???これと同じかな。むしろreadline使うように変えたらどうだいって展開だけど。mac使いじゃなくてごめんよ。
0078NAME IS NULL
2014/04/16(水) 20:59:24.88ID:???お世話になります。
ちょっとだけですが調べたところpostgresql(psql)の問題ではなく、
Macのlibeditの問題のようです。
ということで、これ以上はスレチになりご迷惑になりますので、
ここらで退散します。
ありがとうございました。
かなり大規模なシステムの開発・検証用にMac上でPostgresを使ってみましたが、
この件以外はなにも問題がなかったことだけ付け加えさせていただきます。
0079NAME IS NULL
2014/04/17(木) 15:31:49.61ID:???具体的には日本時間と中国時間、世界標準時を見たいです。
0080NAME IS NULL
2014/04/17(木) 16:10:19.43ID:???http://www.postgresql.jp/document/9.3/html/functions-datetime.html#FUNCTIONS-DATETIME-ZONECONVERT
例として
select now() at time zone 'GMT';
のようにすれば世界標準時が見れる。
0081NAME IS NULL
2014/04/20(日) 09:47:00.81ID:???select t1.*, t2.* from t1, t2 where t1.id = t2.id
だと、クロスジョインが作られた後にフィルタがかかるけど、
select t1.*, t2.* from t1 join t2 on t1.id = t2.id
だと、クロスジョインを作ることなく、フィルタしながら結合する、
という理解であってますか。
また前者はクロスジョインを作るのでメモリ消費量が多い、後者は作らないのでメモリ消費量が少ない、であってますか。
0082NAME IS NULL
2014/04/20(日) 09:55:18.55ID:???いいえ。バージョンにもよるが、どちらもフィルタしながら結合することになる。
EXPLAINを先頭につけて実行計画を見てみるといい。それなりに賢く動いてくれるよ。
0083NAME IS NULL
2014/04/20(日) 10:46:35.45ID:???じゃあ、from t1, t2 where t1.id = t2.id と from t1 join t2 on t1.id = t2.id は、（厳密ではないにしてもだいたい）同じ実行計画になるというわけですか。
この場合、両者に違いはないという理解でいいでしょうか。
0084NAME IS NULL
2014/04/20(日) 11:22:39.62ID:???バージョンによって俺らの理解と違う動きをすることはままある。
0085NAME IS NULL
2014/04/20(日) 12:13:58.74ID:???なるほど。
実行計画以外での、違いは何かありますか。
たとえば count(*) と count(column) って、似てるようで微妙に違いがありますよね。
そんなかんじで、from t1, t2 where t1.id=t2.id と from t1 join t2 on t1.id=t2.id にも
初心者が知らない違いがあるかもとおもって質問しました。
0086NAME IS NULL
2014/04/20(日) 12:54:11.09ID:???SQLの仕様がわからないのか、実行計画などの実装がわからないのかどっちだ？
count(*) と count(column) は、仕様レベルで違うぞ？ NULLを数えるか否かが異なる。
結合のほうは、仕様としては同じ結果を返すだろう？
そして実装（内部動作）は、どうしてもバージョンや設定に依存する。
以前は JOIN vs IN vs EXISTS で、結果は同じでも速度が変わるなんてのもあったが、
最近のバージョンだと最適化されて同じ動作になることもあるくらいだ。
初心者ならば、まずはやるべきことを過不足無くSQLに落とすべし。
最適化を考えるのは、EXPLAINを読めるようになってからだ。
0087NAME IS NULL
2014/04/20(日) 14:28:47.13ID:???> count(*) と count(column) は、仕様レベルで違うぞ？ NULLを数えるか否かが異なる。
いやだからさ、その2つが違うことは>85で書いてるじゃん。
同じように見えても実は違いがある、だからfrom t1, t2 where ... と from t1 join t2 on ... も、同じように見えてなにか違いがあるのかを聞いているの。
最初はクロスジョインを作る・作らないの違いがあると思ってたけど、その違いはないらしいから、じゃあどんな違いがあるのか（それともまったく同じなのか）を質問しているんだが。
そんなに分かりにくいか？
0088NAME IS NULL
2014/04/20(日) 14:51:30.96ID:???「似てるようで微妙に」なんて表現は使っているから、理解できていないように見えるんだよ。
そもそも異なる結果を求めるクエリなんだから、「微妙」ではない違いがある。
一方、from t1, t2 where ... と from t1 join t2 on ... は、同じ結果になるクエリなんだろう？
だったら、まともなDBMSを使っていれば、「まったく同じ」に扱われることを期待してよいだろう。
SQLは「どう処理するか」ではなく、「何が欲しいか」を記述する言語であることを留意せよ。
「クロスジョインを作る」か否かという実装まで意識するのは、次のステップとして学べばいい。
0089NAME IS NULL
2014/04/21(月) 00:32:40.53ID:???> 結合のほうは、仕様としては同じ結果を返すだろう？
そんなに分かりにくいか？
0090NAME IS NULL
2014/04/21(月) 10:23:02.76ID:???0091NAME IS NULL
2014/04/21(月) 15:36:17.86ID:???なんでexplain使わないで質問するんだろ？explainみれば済むのに。
count(*)もcount(column)もexplainみれば、最後の最後に同じ処理で集計してるって分かるだろうに。
0092NAME IS NULL
2014/04/21(月) 15:53:40.72ID:???> explainみれば済むのに。
には同意するけど、
> count(*)もcount(column)もexplainみれば、最後の最後に同じ処理で集計してるって分かるだろうに。
に関しては、同じ処理になるとは限らないよ。設計上の差が無ければ count(*) のほうがお得。
(ver.9.3)
SET enable_seqscan = off;
EXPLAIN (COSTS false) SELECT count(*) FROM pg_class;
Aggregate
-> Index Only Scan using pg_class_oid_index on pg_class
EXPLAIN (COSTS false) SELECT count(reloptions) FROM pg_class;
Aggregate
-> Seq Scan on pg_class
0093NAME IS NULL
2014/04/21(月) 16:45:41.91ID:???それがお勉強ってもんだろ
0094NAME IS NULL
2014/04/21(月) 23:38:53.00ID:???0095NAME IS NULL
2014/04/21(月) 23:44:19.22ID:???0096NAME IS NULL
2014/05/01(木) 16:41:16.90ID:???同一サーバで、DB単位に別々のタイムゾーンを設定する方法はないでしょうか？
0097NAME IS NULL
2014/05/01(木) 17:17:08.63ID:???0098NAME IS NULL
2014/05/01(木) 17:19:27.65ID:???それで設定すると、すべてのタイムゾーンがその値になります。
分けたいんですよ、DBごとに
0099NAME IS NULL
2014/05/01(木) 17:21:34.89ID:???0100NAME IS NULL
2014/05/01(木) 17:22:30.88ID:???SETではどう？
0101NAME IS NULL
2014/05/01(木) 17:23:42.71ID:???これまでは国内向けだけだったんで問題なかったんですが、タイムゾーンが異なる地域からも需要が発生して、それぞれの地域のタイムゾーンに合わせて使い分けたいわけです。
0102NAME IS NULL
2014/05/01(木) 17:24:32.75ID:???一緒ですよ
0103NAME IS NULL
2014/05/01(木) 17:25:38.59ID:???SET TIMEZONE TO 'なんちゃら' で毎回設定しては？
0104NAME IS NULL
2014/05/01(木) 17:26:24.28ID:???クラスタごとです。
set 何とかとかでわけられるんですか？
0105NAME IS NULL
2014/05/01(木) 17:28:03.08ID:???set タイムゾーン ってのがあるんですね？
初めて知りました。
調べてみます。
まさにそれみたいです
（あるんなら）
0106NAME IS NULL
2014/05/01(木) 17:31:53.15ID:???それなら、なおさらサーバやDBのタイムゾーンは
GMT(グリニッジ世界標準時間)で統一すべき
そしてサービス単位に地域に応じたローカル時間、
たとえば日本であればJSTで運用するのが普通の考え方
0107NAME IS NULL
2014/05/01(木) 17:34:47.74ID:???今から思えばそうですが、まさかタイムゾーンが異なる地域からの需要が発生するなんて思っても見なかったんです。
さすがにワールドワイドですね(・。・)
0108NAME IS NULL
2014/05/01(木) 17:41:09.15ID:???歴史的な問題（？）があってずっとEUCJPで運用してました。
DBをEUCJPからUTF8に変換する際にも、こちらで非常にお世話になりました m(_ _)m
0109NAME IS NULL
2014/05/01(木) 20:17:52.86ID:???もしかして: 歴史的経緯
0110NAME IS NULL
2014/05/09(金) 10:32:14.16ID:???それぞれ PRIMARY KEY である id 列があり、その他10～20数個の列があります。
table a と table b のレコード数はそれぞれ50万～100万行程度です。
で、今、
# select b.id from b where b.id not in (select a.id from a);
ってやってるんですが、全然終わりません(泣)
多分、結果はゼロか数行程度です。
サーバの負荷が高いままなんで困ってます。
なにがいけないんでしょう？
中断したほうがいいですか？
0111NAME IS NULL
2014/05/09(金) 10:47:51.51ID:???# explain select b.id from b where b.id not in (select a.id from a);
とすれば、検索がどのように処理されるのかわかる。
a.idにはインデックスが貼ってあるの？
0112NAME IS NULL
2014/05/09(金) 10:49:25.47ID:???ありがとうございます。
a.id にも b.id にもインデックスが貼ってあります。
explain は実際には実行しないのですか？
一旦中断してから explain するんですね？
0113NAME IS NULL
2014/05/09(金) 10:50:43.44ID:???aとbにそれだけのレコード数があれば結合に少し時間がかかるかもれない。
0114NAME IS NULL
2014/05/09(金) 10:51:28.51ID:???一旦中断してしまうと、また再度これ以上の時間がかかるのかと心配です。
0115NAME IS NULL
2014/05/09(金) 10:52:34.80ID:???止めなくてもほかのクライアントを立ち上げてもいいよ。
explain 文は実行しても実際に検索処理はされない。
0116NAME IS NULL
2014/05/09(金) 12:41:19.82ID:???explain analyze ・・・
と続ける
0117NAME IS NULL
2014/05/09(金) 12:48:47.99ID:???致命的に間違ってるってことはないですよね？
このまま続けても大丈夫なんでしょうか？
0118NAME IS NULL
2014/05/09(金) 12:50:56.27ID:???0119NAME IS NULL
2014/05/09(金) 12:52:27.94ID:???まあとっとと止めて、対策してやりなおしたほうが早そうだけどな
0120NAME IS NULL
2014/05/09(金) 12:56:31.96ID:???50万行にnot inを50万回だろ
50万行をオンメモリにでもできれば最適化できるかも知れんけど
0121NAME IS NULL
2014/05/09(金) 13:03:00.65ID:???えっと、table b が50万行で、table a が100万行だったんで、
50万行の各行に対してそれぞれ100万回ずついちいち調べてるってことですか？
でも、DBMS ってそこんとこ(?)上手くやってくれるんじゃぁ？
0122NAME IS NULL
2014/05/09(金) 13:03:45.70ID:???10分反応なければ次のSQL
0123NAME IS NULL
2014/05/09(金) 13:07:57.42ID:???そうなんですか？
逐次処理的に考えると、50万×100万で、500,000,000,000 回になりますが？
0124NAME IS NULL
2014/05/09(金) 13:13:33.82ID:???5000億？
その件数を読みたいなら待てば良い
一つのSQLでむりなら複数組み合わせるかシェル使うかな
考え方変えるか待つかだろ？
0125NAME IS NULL
2014/05/09(金) 13:22:34.81ID:???いえ、>>122 が、「たかが100万」ってことだったんで、
50万行に対して not in が100万あるんですけど？と確認しただけです。
table a の id も table b の id もそれぞれ PRIMARY KEY で、
もちろん UNIQUE なので、サブクエリも思い浮かばないんですが
0126NAME IS NULL
2014/05/09(金) 13:36:07.24ID:???SQL歴何日？
0127NAME IS NULL
2014/05/09(金) 13:47:09.70ID:???それがどう関係ある？
仮に10年の経験があっても、122 みたいなトンチンカンな奴はどうしようもないだろ？
おまえもな
0128NAME IS NULL
2014/05/09(金) 13:53:07.55ID:???いったんとめてEXPLAINしたり、件数絞ったSQL書いて
だいたいどれくらいかかるのか予測できるくらいの材料出して
それから対策を考える
最終的には1分以内で出せるようになると思うがな
0129NAME IS NULL
2014/05/09(金) 14:01:51.90ID:???10年やっててこんな所でなやんでたらとっとと辞めてくれ
周りが迷惑してるぞ
0130NAME IS NULL
2014/05/09(金) 14:08:32.86ID:???おまえ、あほだろ？
0131NAME IS NULL
2014/05/09(金) 14:12:27.19ID:???うん
あほだけど
こんな問題を2chで教えてもらうほどのバカではない
0132NAME IS NULL
2014/05/09(金) 14:14:22.07ID:???その場合、1分とか10分とかのオーダーで終わるわけがない
チューニングどうこうのレベルじゃないよ
0133NAME IS NULL
2014/05/09(金) 14:20:00.28ID:???もちろんテーブル追加や構造を変えることも視野に入れてだが。
0134NAME IS NULL
2014/05/09(金) 14:27:37.72ID:???0135NAME IS NULL
2014/05/09(金) 14:27:52.12ID:???それが絞り込むってことだろ？
大丈夫か、おまえ？
0136NAME IS NULL
2014/05/09(金) 14:32:10.68ID:???それで使える物ならね
普通はまてないから別の手探すだろう
0137NAME IS NULL
2014/05/09(金) 15:04:29.85ID:???（正）頭の悪い奴多そう
0138NAME IS NULL
2014/05/09(金) 15:14:01.33ID:???だから絞り込む条件が無いなら作るんだよ、タイムゾ－ン君
0139NAME IS NULL
2014/05/09(金) 15:15:40.40ID:???0140NAME IS NULL
2014/05/09(金) 16:04:46.23ID:???機械がおそいから・・・
無理な要求だから・・・
とかいうのかな？
どんな手を考えてあのSQL一発って結論になったんだろ？
0141NAME IS NULL
2014/05/09(金) 20:54:09.18ID:???select b.id from b right join a using (id) where a.id is null
select id from b except all select id from a
あたりでも試してみれば。
てか、質問者は名前にレス番入れるくらいしなよ。
0142NAME IS NULL
2014/05/10(土) 04:18:38.10ID:???index only scanが実装されてるバージョンなら、元のやつも速くなったりすんのかなぁ。
使える場面ではあるはずだよね。
0143NAME IS NULL
2014/05/10(土) 17:03:56.56ID:???これは件数が多いと悲惨なことになる
select b.id from b where not exists (select * from a where a.id=b.id);
なら10分もかかからず終わると思うよ
0144NAME IS NULL
2014/05/10(土) 21:45:44.24ID:???『他のテーブルに存在しない行を探すには』 ttp://postgresql.g.hatena.ne.jp/pgsql/20110302
遅いのは、単にANALYZEしてないか、work_memが小さすぎるんじゃないの？
0145NAME IS NULL
2014/05/10(土) 22:03:41.47ID:???その例はインデックスすら張ってないじゃないか
話にならん
0146NAME IS NULL
2014/05/10(土) 22:23:18.21ID:???安定して速度が出るのはハッシュジョイン系の実行計画だよ。件数やインデックスに関係ない。
十分に検証になっていると思うがね。
0147NAME IS NULL
2014/05/10(土) 22:35:23.62ID:???元質問は「何時間もおわらないSQLどうしたら良い？」なんだから
やり直せでいいでしょう
0148110
2014/05/10(土) 22:44:18.70ID:???>>110 で質問させていただいたものです。
結果だけ報告させて頂きます。
> select b.id from b where b.id not in (select a.id from a);
これは結局3時間目で諦めました。
いつ終わるか予測がつかなかったからです。
で、
>>143 の方に示していただいた、
>select b.id from b where not exists (select * from a where a.id=b.id);
ですが、よく理解できなかったんですが、半信半疑で試しました。
結果、驚きの
Total runtime: 1478.876 ms
です！
未だに信じられないです。
50万行と100万行ですよ！3時間でも終わらなかったのに！
結果が正しいか検証しましたが、正しかったです。
>>143 ありがとうございましたm(__)m
もうちょっと勉強します。
0149NAME IS NULL
2014/05/11(日) 01:38:19.10ID:???ところで>>141はスルー？まぁ、速くなったならなんでもいいけど
0150NAME IS NULL
2014/05/11(日) 01:40:18.63ID:???実行計画は件数やインデックスによって変わってくるけど、、、という話は別にいっか。
分かってそうな人だし。
0151NAME IS NULL
2014/05/11(日) 06:41:19.23ID:???実行計画が状況によって変わるのと、どんな実行計画を目指すのかは別の問題じゃない？
まぁ >>148 が NOT EXITS で速くなったんだから、NOT IN が万能ではなさそうだけど。
0152NAME IS NULL
2014/05/11(日) 07:15:00.43ID:???ハッシュジョインは確かにインデックスの有無によらず速度は安定しているだろうが、
決して速くはないな。
0153110
2014/05/11(日) 12:48:32.07ID:???失礼しました m(__)m
>select b.id from b right join a using (id) where a.id is null
こちらは実行できませんでした。
ERROR: USING句で指定した列"idが左テーブルに存在しません
入れ替えても
ERROR: USING句で指定した列"idが右テーブルに存在しません
となります。
>select id from b except all select id from a
こちらは、
Total runtime: 3684.640 ms
で終了しました。
>>143 の方に示していただいた、
>select b.id from b where not exists (select * from a where a.id=b.id);
よりは遅かったです。
ということで、not exists 最速ってことですね。
行数が多いと、 not in 使えないですね。
色々とありがとうございます。
0154NAME IS NULL
2014/05/11(日) 13:44:11.28ID:???必ずしも IN より EXISTS が速いかというとそうも言えないという例もある。
NOT が絡むとまた違うのかもしれないが。
http://d.hatena.ne.jp/tgk/20081225/1230202069
結論としてはANALYZEして実行計画を見ながら調整するのがいいんじゃないかな。
0155NAME IS NULL
2014/05/11(日) 13:55:10.79ID:???NOT INがEXPLAINでHASH ANTI JOINになってるかどうかを知りたいな
多分なってないから起きたことかと思うんだ
0156NAME IS NULL
2014/05/11(日) 14:01:37.60ID:???そのリンクのPostgreSQLの話は8.3までだな8.4から大幅に変わってる
副問い合わせ部分の件数が十分に多いときはEXISTSが速くて
少ないときはINが速いのがもともとの仕様よね
それをオプティマイザがどこまで最適化できるか
0157154
2014/05/11(日) 14:05:53.32ID:???ごめん。情報古すぎたね。
的確なコメントありがとう。
本件で一番わかりやすいコメントだと思う。
質問者には届かないだろうけど(笑)
0158NAME IS NULL
2014/05/11(日) 15:24:25.01ID:???検証おつかれさま。
> それぞれ PRIMARY KEY である id 列があり
なのに、id列が見つからないというエラーは不思議なもんですね。
0159NAME IS NULL
2014/05/15(木) 15:00:18.28ID:???・not in では3時間でも終わらない
・not exists では、1.5秒以下で終る
ってのは、にわかには信じられんなぁ
それだけの件数だとちょっと検証も難しいけど
0160NAME IS NULL
2014/05/15(木) 15:25:55.09ID:???CREATE TABLE a AS (SELECT generate_series(1,1000000) AS id)
ALTER TABLE a ADD primary key (id);
CREATE TABLE b AS (SELECT generate_series(1,500000) AS id)
ALTER TABLE b ADD primary key (id);
ANALYZE a;
ANALYZE b;
EXPLAIN SELECT b.id FROM b WHERE b.id NOT IN (SELECT a.id FROM a);
Seq Scan on b (cost=0.00..8045010172.00 rows=250000 width=4)
Filter: (NOT (SubPlan 1))
SubPlan 1
-> Materialize (cost=0.00..29680.00 rows=1000000 width=4)
-> Seq Scan on a (cost=0.00..17844.00 rows=1000000 width=4)
EXPLAIN SELECT b.id FROM b WHERE NOT EXISTS(SELECT * FROM a WHERE a.id = b.id);
Merge Anti Join (cost=0.85..34723.67 rows=1 width=4)
Merge Cond: (b.id = a.id)
-> Index Only Scan using b_pkey on b (cost=0.42..13624.42 rows=500000 width=4)
-> Index Only Scan using a_pkey on a (cost=0.42..27240.42 rows=1000000 width=4)
0161NAME IS NULL
2014/05/15(木) 15:30:30.38ID:???SetOp Except All (cost=216147.98..223647.98 rows=500000 width=4)
-> Sort (cost=216147.98..219897.98 rows=1500000 width=4)
Sort Key: "*SELECT* 1".id
-> Append (cost=0.00..41766.00 rows=1500000 width=4)
-> Subquery Scan on "*SELECT* 1" (cost=0.00..13922.00 rows=500000 width=4)
-> Seq Scan on b (cost=0.00..8922.00 rows=500000 width=4)
-> Subquery Scan on "*SELECT* 2" (cost=0.00..27844.00 rows=1000000 width=4)
-> Seq Scan on a (cost=0.00..17844.00 rows=1000000 width=4)
EXPLAIN SELECT b.id FROM b LEFT JOIN a USING (id) WHERE a.id is null
Merge Anti Join (cost=0.85..34723.67 rows=1 width=4)
Merge Cond: (b.id = a.id)
-> Index Only Scan using b_pkey on b (cost=0.42..13624.42 rows=500000 width=4)
-> Index Only Scan using a_pkey on a (cost=0.42..27240.42 rows=1000000 width=4)
0162NAME IS NULL
2014/05/15(木) 19:33:03.28ID:???なかなか面白い結果だね。
ちなみにwork_memを増やしたら hashed SubPlan になった。計算上のコストは最安値かな。
ノウハウ的には「NOT INでは十分work_memを割り当てるべし。足りないと糞遅い」ってとこか。
SET work_mem = '64MB';
EXPLAIN SELECT b.id FROM b WHERE b.id NOT IN (SELECT a.id FROM a);
Seq Scan on b (cost=16925.00..25388.00 rows=250000 width=4)
Filter: (NOT (hashed SubPlan 1))
SubPlan 1
-> Seq Scan on a (cost=0.00..14425.00 rows=1000000 width=4)
0163NAME IS NULL
2014/05/16(金) 00:35:35.38ID:???でも実行計画はほとんどSQLの字面通りって感じで、そんなに賢いわけじゃなさそうだな。
0164NAME IS NULL
2014/05/16(金) 03:02:17.32ID:???どういう実行計画になればいいなぁと思ってるのかおしえてもらえると嬉しいです
0165NAME IS NULL
2014/05/16(金) 07:12:46.71ID:???0166NAME IS NULL
2014/05/16(金) 13:51:40.68ID:???仮検証はidだけでテーブル作ったけど
他のカラムもあるとNOT INは遅くなってしまうよ
0167NAME IS NULL
2014/05/16(金) 16:07:49.11ID:???NOT IN で他のカラムがある場合に遅くなるのはテーブルの SeqScan のところ。
一方、NOT EXISTS で使われている Index Only Scan は更新してゴミが残っていると遅くなる。
状況次第じゃないかな？キャッシュサイズにも影響を受けそう。
どちらかというと、同じ結果になるはずなのに、プランが同じにならないのが気になるな。
どの書き方でも、DB側が状況を判断して速いほうを使ってくれるのが一番うれしいんだけど。
0168NAME IS NULL
2014/05/16(金) 17:04:30.22ID:???0169110
2014/05/16(金) 17:28:58.68ID:???Postgres 特有のものなんですかね？
私は他の DBMS を使ってないんで分からないですが
0170NAME IS NULL
2014/05/16(金) 17:43:46.04ID:???他のRDBMSでも同様に起こりえます。どこまで最適化できるかはあるけどね
0171NAME IS NULL
2014/05/16(金) 21:06:16.21ID:???(cost=0.00..41766.00 rows=1500000 width=4)
これらの意味や考え方を解説してある良いところどこでしょうか？
0172NAME IS NULL
2014/05/16(金) 22:33:40.56ID:???マニュアルの「14.1. EXPLAINの利用」とか
0173NAME IS NULL
2014/05/17(土) 10:30:59.86ID:???最近は両方同じように最適化するから差はないということになってるけど解析による。
最初にEXPLAINしろといったのはEXISTSと比較するためだったんだよ。
当人がなかなか結果を書かないから言い出せなかっただけ
0174NAME IS NULL
2014/05/17(土) 11:53:51.87ID:???君が言い出せなくても、別に何も影響はなかったな
0175NAME IS NULL
2014/05/17(土) 12:41:49.44ID:???それがその日に解決するか4日かかるかの違いだけだ。
0176NAME IS NULL
2014/05/17(土) 12:49:18.54ID:???0177NAME IS NULL
2014/05/17(土) 12:59:15.94ID:???0178NAME IS NULL
2014/05/17(土) 13:02:54.77ID:???５分や１０分で終わるわけ無い
って言ってた人も居たね
最近書き込んでるのかな？
俺なら恥ずかしくて来られなくなるな
0179NAME IS NULL
2014/05/17(土) 13:13:01.08ID:???同じように計算されることはないと思うんだよね
EXISTSとINNER JOIN、NOT EXISTSとLEFT JOINは同じだから
オプティマイザがちゃんとしてれば等価になる
そこらへんを勘違いすると
http://kkoudev.github.io/blog/2013/09/14/sql/
となる。MySQLかな？
0180NAME IS NULL
2014/05/17(土) 16:15:43.35ID:???NULLがある場合には、結果が異なるみたいだね。
実装としては、ほとんどのDBでINは「INの中が先に処理されて、中間結果がキャッシュされる」っぽい。
処理に順序がでるから、(hashed) SubPlan は使えても、JOIN関連は使われないんだね。
0181NAME IS NULL
2014/05/17(土) 18:21:03.27ID:???賢いオプティマイザってもんだな。
0182NAME IS NULL
2014/05/22(木) 19:03:15.79ID:???PostgreSQLが追記型という点でMySQLなどに対して寿命に関するアドバンテージがありそうな気がするのだけれど
実際のところどうなのでしょう？追記型でなくともSSDのファームウェアがよきにはからってくれそうな気がするし。
検索の仕方が悪いのか、比較したページが見つからない・・・だれか何かご存知ですか？
0183NAME IS NULL
2014/05/22(木) 19:05:34.11ID:???そうじゃない場合は必要なフィールドだけ修正するから実際の書き込みサイズは小さいのかな。
そうすると PostgreSQL は分が悪い？
0184NAME IS NULL
2014/05/25(日) 21:22:40.35ID:???ViewTable ってのがあると思います。
いまとても長い SQL があって、それを実行のたびに打ち込んでいるのですが、
この SQL は複数のテーブルの結合のために副問い合わせを多用していて最後の部分に抽出用の条件がついています。
この場合、最後の抽出の部分以外はいつも解釈が変わるわけでもないので、
ViewTable で最後の条件式以外の部分をテーブルとして作成しておいて、
これに対して抽出を掛ける方が速度的に有利な気がしました。
これは正しいでしょうか。
‥‥と、むかし、DB にはそういう機能もあるとお勉強した気がするのですが、それは Postgre の ViewTable で実現できるのでしょうか。
別なテーブル(機能)と勘違いしてるかもと気になりました。
0185NAME IS NULL
2014/05/25(日) 21:44:55.62ID:???マテリアライズドビューを使えばできるよ
9.3からな
0186NAME IS NULL
2014/05/25(日) 21:46:45.15ID:???viewはおなじ抽出条件を何度も書かなくて済むようにするためのマクロみたいなもので、
あんたの目的にはこれで十分。
中間結果を実体のテーブルに保存するのはmaterialized viewというもので、速くなるか
逆に遅くなるかは場合による。そのへんが理解できてから使えばいい。
0187NAME IS NULL
2014/05/25(日) 22:18:36.42ID:???ありがとう。
materialized view を確認してみるです。
言われてみれば、たしかに今のところは view table で十分な気もしますね。。
0188NAME IS NULL
2014/05/31(土) 21:30:10.19ID:???一旦文字列をtimestampに変換の上、比較しないとダメでしょうか？
具体的にはこんな感じですが
sql = "SELECT * FROM hoge WHERE hoge_date < CAST(:p1 AS TIMESTAMP)"
Using cmd = New NpgsqlCommand(sql, conn, trn)
cmd.Parameters.Add("p1", NpgsqlTypes.NpgsqlDbType.Varchar).Value = DateTime.Parse(row(0)).ToString("yyyy-MM-dd HH:mm:ss.ff")
Dim dr As Npgsql.NpgsqlDataReader = cmd.ExecuteReader()
End Using
これだとエラーになります
sql = "SELECT * FROM hoge WHERE hoge_date < :p1"
Using cmd = New NpgsqlCommand(sql, conn, trn)
cmd.Parameters.Add("p1", NpgsqlTypes.NpgsqlDbType.Timestamp).Value = Now()
Dim dr As Npgsql.NpgsqlDataReader = cmd.ExecuteReader()
End Using
0189NAME IS NULL
2014/05/31(土) 21:55:07.71ID:???エラー内容何よ？
0190NAME IS NULL
2014/06/01(日) 01:19:27.46ID:???Npgsqlを直接呼び出すのはやっていないんで、間違っているかもしれないけれど、
NpgsqlTypes.NpgsqlDbType.Timestamp を System.Data.DbType.DateTime
にしたらどう?
0191188
2014/06/02(月) 10:46:41.06ID:???指定されたキャストが無効ですというエラーだったのですが、
↓だとエラーが出て文字列型を入れてたので当然でした・・・
cmd.Parameters.Add("p1", NpgsqlTypes.NpgsqlDbType.Timestamp).Value = DateTime.Parse(hoge).ToString("yyyy-MM-dd HH:mm:ss.ff")
OK
cmd.Parameters.Add("p1", NpgsqlTypes.NpgsqlDbType.Timestamp).Value = DateTime.Parse(DateTime.Parse(hoge).ToString("yyyy-MM-dd HH:mm:ss.ff"))
0192NAME IS NULL
2014/06/03(火) 00:12:02.88ID:???たまに急に接続できなくなるんだけど
0193NAME IS NULL
2014/06/15(日) 03:24:41.04ID:???なんでODBCが原因って思った？
0194NAME IS NULL
2014/06/20(金) 09:44:44.42ID:d5MGxn3/★+ニュース板
・ 2NN (推奨サイト)
・ 2chTimes
★+ニュース板新着
・ 2NN新着
・ Headline BBY
・ unker Headline
★+ニュース板その他
・ Desktop2ch
・ 記者別一覧
★全板
・ 全板縦断勢いランキング (推奨サイト)
・ スレッドランキング総合ランキング
・ ログ速
★全板実況込み
・ 2勢 (推奨サイト)
・ READ2CH
・ i-ikioi
※ 要タイトル検索
※ 2chブラウザ併用推奨
0195NAME IS NULL
2014/06/24(火) 00:02:00.17ID:???後者はコストが桁違いに高くてフィルタした数も尋常じゃないこの状態の理由おしえてもらえないでしょうか…？
タイムアウトを解消しようと思って検証をはじめたんですが、解析結果が理解できず詰まっています。
explain analyze SELECT "posts".* FROM "posts" WHERE (true) AND (posts.tag_index @@ to_tsquery('danbooru', E'(''nintendo'')')) ORDER BY posts.id DESC LIMIT 40 OFFSET 0"
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..2649.78 rows=40 width=698) (actual time=0.098..9.179 rows=40 loops=1)
-> Index Scan Backward using posts_pkey on posts (cost=0.00..1169216.46 rows=17650 width=698) (actual time=0.095..9.156 rows=40 loops=1)
Filter: (tag_index @@ '''nintendo'''::tsquery)
Rows Removed by Filter: 2635
Total runtime: 9.330 ms
(5 rows)
explain analyze SELECT "posts".* FROM "posts" WHERE (true) AND (posts.tag_index @@ to_tsquery('danbooru', E'(''luriastis_t_mikuriya'')')) ORDER BY posts.id DESC LIMIT 40 OFFSET 0"
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=0.00..13024.40 rows=40 width=698) (actual time=68.574..1393196.913 rows=15 loops=1)
-> Index Scan Backward using posts_pkey on posts (cost=0.00..1167963.05 rows=3587 width=698) (actual time=68.571..1393196.895 rows=15 loops=1)
Filter: (tag_index @@ '''luriastis_t_mikuriya'''::tsquery)
Rows Removed by Filter: 3773176
Total runtime: 1393197.013 ms
(5 rows)
0196NAME IS NULL
2014/06/24(火) 04:25:36.85ID:???posts.tag_indexにはインデックスが作成されている？
どちらのクエリもposts.idを逆順にスキャンしているけど
後者の条件posts.tag_index @@ to_tsquery('danbooru', E'(''luriastis_t_mikuriya'')')
を満たす行がposts.idの若い番号に偏っているのが原因のように思われる。
0197NAME IS NULL
2014/06/24(火) 09:23:49.57ID:???後者は3773191件中15件しかないから全件調べてるからだよな
インデックスから調査だね
analyzeが適切に行われてないと難しいクエリだね
0198NAME IS NULL
2014/06/24(火) 12:38:41.74ID:???indexが怪しいという指摘の通りでした。ありがとうございました。
posts_pkeyは単なるidのindexで、このクエリでの利用を想定していたindexではありませんでした。
それでindex_posts_on_tags_indexというGINインデックスが利用されていないことが理由だと分かったので、
そのインデックスが利用されるようにクエリを書き換え調べてみたんですが、
to_tsqueryに単語を二件以上指定するとインデックスが利用されるようでしたので（？）、
入力キーワードが一件だった場合は以下のようにすることで、適切にインデックスを利用してくれるようになりました。
explain analyze SELECT "posts".* FROM "posts" WHERE (true) AND (posts.tag_index @@ to_tsquery('danbooru', E'(''luriastis_t_mikuriya & luriastis_t_mikuriya'')')) ORDER BY posts.id DESC LIMIT 40 OFFSET 0"
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=14712.02..14712.03 rows=1 width=695) (actual time=120.823..120.823 rows=0 loops=1)
-> Sort (cost=14712.02..14712.03 rows=1 width=695) (actual time=120.822..120.822 rows=0 loops=1)
Sort Key: id
Sort Method: quicksort Memory: 25kB
-> Bitmap Heap Scan on posts (cost=14708.00..14712.01 rows=1 width=695) (actual time=120.787..120.787 rows=0 loops=1)
Recheck Cond: (tag_index @@ '''luriastis_t_mikuriya'' & ''&'' & ''luriastis_t_mikuriya'''::tsquery)
-> Bitmap Index Scan on index_posts_on_tags_index (cost=0.00..14708.00 rows=1 width=0) (actual time=120.783..120.783 rows=0 loops=1)
Index Cond: (tag_index @@ '''luriastis_t_mikuriya'' & ''&'' & ''luriastis_t_mikuriya'''::tsquery)
Total runtime: 120.980 ms
(9 rows)
0199NAME IS NULL
2014/06/24(火) 13:51:24.17ID:???>to_tsqueryに単語を二件以上指定するとインデックスが利用されるようでしたので（？）、
コスト計算に問題があって、posts_pkeyを利用した方がコストが低いと出てるから使われてないんだね
ANALYZEはちゃんとかけてますか？
0200NAME IS NULL
2014/06/26(木) 19:34:58.80ID:???0201NAME IS NULL
2014/06/26(木) 19:36:56.52ID:???0202NAME IS NULL
2014/06/26(木) 21:32:02.53ID:???なるほど、コスト計算の問題なんですね。
ANALYZEはどういうものか事前に知っていたため、クエリ発行前に実行していました。
元々このシステムは8系の環境で作られたものなんですが、手元で動かしている環境は9.2なので、
バージョンの問題なのかなと思ってますが…、正直なところ全く分かっていません。
他にも8系で動かしてたころからdumpしたデータのexport/importを繰り返していたり、
一度ロケールを変更したりと怪しいことをした記憶はいくつかあります。
0203NAME IS NULL
2014/07/01(火) 13:50:20.75ID:???ストアドにテーブルのレコードを全件食わせたいのです。
(再計算させる処理を作っています。)
試してみたこと。
１． SELECT func(t1.id, t1.data1, t1.data2) FROM table1 t1;
結果は出るが、フィールド名funcで全部まとめて出る。
２． SELECT f1.id, f1.res1, f1.res2, f1.res3 FROM func(t1.id, t1.data1, t1.data2) f1, table1 t1;
エラー。
カーソル使って1件づつ食わせるしかないのでしょうか？
0204NAME IS NULL
2014/07/01(火) 14:30:25.26ID:???もう少し厳密な言葉で説明して欲しいところだが、てきとーに推測すると、
SELECT (func(t1.id, t1.data1, t1.data2)).* FROM table1 t1;
でどうだろうか？
0205203
2014/07/01(火) 14:30:41.91ID:???CREATE FUNCTION func_test1()
RETURNS Set Of table_ret AS
$$
DECLARE
table1row table1%ROWTYPE;
BEGIN
FOR table1row IN SELECT * FROM table1 LOOP
RETURN QUERY SELECT * FROM func(table1row.id, table1row.data1, table1row.data2);
END LOOP;
END;
$$
LANGUAGE plpgsql;
SELECT * FROM func_test1();
もっとシンプルに出来ないものかorz
0206NAME IS NULL
2014/07/01(火) 14:32:34.13ID:???ありが㌧。出来ました。
0207NAME IS NULL
2014/07/07(月) 10:21:35.64ID:???店舗テーブル
tenpo_id | namae
001 | A店
002 | B店
003 | C店
在庫テーブル
hinban_id | hinmei | zaiko
PCxxxx | Lavie | 10
FMVxxx | Lifebook | 5
PTxxxxx | Dynabook | 7
受注テーブル
tenpo_id | hinban_id | input_timestamp | suuryou
001 | PCxxxx | 2014-07-03 13:30:02 | 3
001 | PTxxxx | 2014-07-03 13:30:02 | 5
003 | PCxxxx | 2014-07-03 13:31:08 | 3
003 | FMVxxx | 2014-07-03 13:31:08 | 1
002 | PCxxxx | 2014-07-04 15:31:08 | 5
こんな感じのテーブル構成で、 ここから、
tenpo_id | hinban_id | input_timestamp | suuryou | zen_zaiko | go_zaiko
001 | PCxxxx | 2014-07-03 13:30:02 | 3 | 10 | 7
001 | PTxxxx | 2014-07-03 13:30:02 | 5 | 7 | 2
003 | PCxxxx | 2014-07-03 13:31:08 | 3 | 7 | 4
003 | FMVxxx | 2014-07-03 13:31:08 | 1 | 5 | 4
002 | PCxxxx | 2014-07-04 15:31:08 | 5 | 4 | -1
こんな感じのデータを取り出すクエリはどう作ればいいのでしょうか？
0208NAME IS NULL
2014/07/07(月) 11:11:14.80ID:???SELECT tenpo_id, hinban_id, input_timestamp, suuryou, suuryou + go_zaiko AS zen_zaiko, go_zaiko
FROM (
SELECT tenpo_id, hinban_id, input_timestamp, suuryou,
zaiko - sum(suuryou) OVER (PARTITION BY hinban_id ORDER BY input_timestamp) AS go_zaiko
FROM 受注テーブル LEFT JOIN 在庫テーブル USING (hinban_id)
) AS T
ORDER BY input_timestamp;
0209NAME IS NULL
2014/07/16(水) 09:16:31.68ID:XvANJ3dDpgpoolにunixドメインで接続する場合の
パラメータは何を指定すればよいでのしょうか？
host指定なしで、portに9999を指定すると
postgresqlにunixドメインで直接つながってしまいます。
0210NAME IS NULL
2014/07/16(水) 10:17:28.13ID:???解決しました。
0211NAME IS NULL
2014/07/24(木) 21:03:15.56ID:???http://www.postgresql.org/about/news/1534/
PostgreSQL 9.4 Beta 2 Released
http://www.postgresql.org/about/news/1533/
0212NAME IS NULL
2014/08/11(月) 11:45:04.98ID:???言語はなんでもかまいません。
0213NAME IS NULL
2014/08/11(月) 11:57:13.05ID:???でも使用追加を前提とした設計に直すべきなんじゃないかなあ
0214NAME IS NULL
2014/08/11(月) 12:08:17.70ID:???アプリ側である整数型の列の何ビット目が立ってるかどうかいちいち判断したり、いちいち特定ビットをオンオフしなくてもSQLで出来るって意味ですか？
0215NAME IS NULL
2014/08/11(月) 12:08:31.19ID:???そのまんまbitとかvarbit型なんてのがなかったっけ。
演算子がどこまで充実していたかは忘れた。contribにあったような気も。
0216NAME IS NULL
2014/08/11(月) 12:11:46.44ID:???0217NAME IS NULL
2014/08/20(水) 04:43:58.02ID:???https://www.postgresql.jp/document/9.3/html/datatype-bit.html
でも、仕様変更で列が増えるなら、黙ってalter tableで明示的に列を追加するのがいいだろ。
何ビット目が何だっけ、ってあとで絶対混乱するから。
0218NAME IS NULL
2014/08/20(水) 07:35:39.60ID:???○この際、テーブル再編を行いたい
おおよその場合こうだと思うんだけども。
0219NAME IS NULL
2014/08/20(水) 11:10:29.83ID:???0220NAME IS NULL
2014/08/21(木) 03:58:06.35ID:???0221NAME IS NULL
2014/08/21(木) 10:48:44.72ID:???仕様変更は、増えることを仕様に入れたほうがいいと思うぜ。
0222NAME IS NULL
2014/08/21(木) 16:11:45.21ID:???ビット列にしてしまって変更前後でデータの意味がDB外で変わったらマイグレの一貫性やテストはどうすんのか知らん
0223NAME IS NULL
2014/08/21(木) 16:18:19.99ID:???元設計が悪いと思うなら、ベストな設計を提示してみろよ。
0224NAME IS NULL
2014/08/21(木) 16:28:00.91ID:???なんどかやればうまくできるようになるよ
0225NAME IS NULL
2014/08/21(木) 16:58:01.34ID:???よくあることじゃない？
ということで>>218を書いたんだけど。
0226NAME IS NULL
2014/08/24(日) 10:54:57.09ID:???0227NAME IS NULL
2014/08/24(日) 11:20:39.92ID:???確かに、教科書的な汎用性の持たせ方なら (アイテムID, フラグID) という
別テーブルを作るのが一番だと思うよ。フラグを好きなだけ増やせるしね。
ただ、パフォーマンスや、追加/削除の手順変更など、気になることがあったんじゃないかな。
0228NAME IS NULL
2014/08/24(日) 12:36:59.55ID:???insert→analyze→selectみたいにしたら数分なんだけど、挟まないと数十時間。
ただ、バッチ処理中でanalyzeみたいなメンテナンス系のコマンド挟むのに抵抗あるんだよな。
同じように悩んでる人居ない？
0229NAME IS NULL
2014/08/24(日) 12:47:51.35ID:???ANALYZEするだけで速くなるんなら、そりゃプランの問題だろう。
大量変更直後に明示的にANALYZEするのなんて普通。避ける必要は無い。
0230NAME IS NULL
2014/08/24(日) 13:19:17.82ID:???悩む理由って？
0231NAME IS NULL
2014/08/25(月) 07:12:04.35ID:???なんとなくアプリケーションロジック内にpostgresの挙動に合わせてメンテナンスコマンド入れるのが気持ち悪いって感じかな。
DBAが計画する定期メンテだけで上手く動いてほしかったという。
けど、それ以外の方法も無さそうだし普通と言ってもらえれば心強い。ありがとう。
0232NAME IS NULL
2014/08/25(月) 17:43:49.07ID:???そんなことが頻繁に起こるシステムなのかしら。
0233NAME IS NULL
2014/09/02(火) 09:56:26.56ID:???エラーコード429
アセンブリ 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=(念のためふせ字)' から
型 'System.Security.Claims.ClaimsIdentity' を読み込めませんでした。
となるのだけれど、原因わかる方、いますか？
0234NAME IS NULL
2014/09/02(火) 12:45:19.02ID:???0235NAME IS NULL
2014/09/02(火) 14:05:54.24ID:???Mono.Security.dll
Npgsql.dll
Npgsql.resources.dll
policy2.0.Npgsql.dll
System.Security.dll
など追加してみてはいるのですが。
0236NAME IS NULL
2014/09/02(火) 14:35:50.15ID:???Openするまでは通常に動くのね？
試しに localhost にインストールしてやってみては
0237NAME IS NULL
2014/09/02(火) 14:41:52.24ID:???参照先を任意のフォルダのNpgsql.dll から、
C:\Program Files\PostgreSQL\Npgsql\ms.net4.0\Npgsql.dll
に変えてみました。
すると、Openする前の
NpgsqlConnection
で、以下のエラーとなりました。
-----------------
'c:\C#Apps\github.npgsql.Npgsql.stock\src\Npgsql\NpgsqlConnection.cs' のソースを検索しています。Checksum: MD5 {3e 98 c 68 60 65 6 88 fc 0 22 41 ad e6 14 34}
ファイル 'c:\C#Apps\github.npgsql.Npgsql.stock\src\Npgsql\NpgsqlConnection.cs' は存在しません。
'c:\C#Apps\github.npgsql.Npgsql.stock\src\Npgsql\NpgsqlConnection.cs' をスクリプト ドキュメント内で探しています...
'c:\C#Apps\github.npgsql.Npgsql.stock\src\Npgsql\NpgsqlConnection.cs' をプロジェクト内で探しています。
ファイルがプロジェクト内に見つかりませんでした。
ディレクトリ 'd:\Program Files\Microsoft Visual Studio 10.0\VC\crt\src\' で探しています...
ディレクトリ 'd:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\src\mfc\' で探しています...
ディレクトリ 'd:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\src\atl\' で探しています...
ディレクトリ 'd:\Program Files\Microsoft Visual Studio 10.0\VC\atlmfc\include\' で探しています...
アクティブなソリューションのデバッグ ソース ファイルの設定では、デバッガーがファイル c:\C#Apps\github.npgsql.Npgsql.stock\src\Npgsql\NpgsqlConnection.cs の検索をユーザーに要求しないことが示されています。
ソース ファイル 'c:\C#Apps\github.npgsql.Npgsql.stock\src\Npgsql\NpgsqlConnection.cs' が見つかりませんでした。
-----------------
0238NAME IS NULL
2014/09/02(火) 15:17:04.40ID:???それ自身はエラーではないのだが、、、
localで試すのはPostgreSQLのことだけど、すでに入ってるっぽいね。
pgAdminIIIは使えてる？
0239NAME IS NULL
2014/09/02(火) 15:45:08.93ID:???XP SP3 32bit VS2010
localhost で、port空けもしておりますし、pgAdminIIIも使えています。
ODBCでは接続OKです。
なんとか、試行錯誤で、やってみます。
0240NAME IS NULL
2014/09/02(火) 15:59:45.43ID:???0241233～239
2014/09/03(水) 10:10:22.86ID:???PostgreSQL 9.3のスタックビルダ(Application Stack Builder)から
ダウンロード、インストールした、
C:\Program Files\PostgreSQL\Npgsql\ms.net4.0\Npgsql.dll
の参照だと、エラーになるようでした。(Npgsql ver 2.0.14.3)
(Framwork3.5 でもエラーになります。ms.net3.5sp1)
別途、
ttp://pgfoundry.org/frs/?group_id=1000140
からダウンロードしたもの解凍、Npgsql.dllを参照すれば、OKになりました。
Npgsql ver 2.0.14.3 でもOK、2.20でもOK
0242NAME IS NULL
2014/09/19(金) 11:22:49.73ID:BxRSG/IE0243NAME IS NULL
2014/10/04(土) 13:25:19.06ID:OfPzGLxRちょっとスマートととは言えないな
もうちょっと簡単にできないだろうか？
0244NAME IS NULL
2014/10/04(土) 14:06:55.16ID:???SELECT tgrelid::regclass AS "テーブル", tgname AS "トリガ", tgfoid::regproc AS "関数名" FROM pg_trigger
0245NAME IS NULL
2014/10/04(土) 17:13:17.27ID:OfPzGLxRすばらしい！勉強になりました。有難う
俺、アホだから、
select distinct event_object_table as "テーブル", trigger_name as "トリガ", TRIM('EXECUTE PROCEDURE ' from action_statement) as "関数名" from information_schema.triggers;
このループから抜け出せなくなってた。思考の飛躍ができなかったよw
0246NAME IS NULL
2014/10/04(土) 17:43:46.85ID:???0247NAME IS NULL
2014/10/04(土) 17:51:16.28ID:oXvTAfcu来週beta3リリースらしいので、
そこから2週でRC、さらに一週間後に9.4.0リリースと考えるなら、
10月末くらいかなあ？
0248NAME IS NULL
2014/10/05(日) 09:47:39.25ID:???0249NAME IS NULL
2014/10/09(木) 22:15:08.05ID:7dkiZZyB0250NAME IS NULL
2014/10/11(土) 18:07:20.37ID:cm1FUS8ZTestDB(Encoding=UTF8,Collate=ja_JP.UTF-8,Ctype=ja_JP.UTF-8)
という空のデータベースがあります。
CREATE TABLE "社員"(
"社員番号" INTEGER PRIMARY KEY NOT NULL,
"社員氏名" TEXT NOT NULL
);
のように、テーブル名、カラム名に日本語を使用したいと思っています。
pgAdmin3を使ってテーブルを作成しようとしたところ、日本語で入力しようとしても、「入力そのもの」を受け付けてくれません。
そこで、コンソール(LXTerminal)でSQLで入力しようとしたところ「社員」と打ち込んでも「社員」という風に確定文字になりません。
IMEの動作不具合ではなく、あきらかに、日本語文字を拒否している感じです。
英単語なら、問題なくテーブルを作成できます。
なにが悪いのでしょうか？
0251NAME IS NULL
2014/10/11(土) 18:19:42.89ID:???> 日本語文字を拒否している感じ
面白い表現を使うなぁ。エラーメッセージは何も無いのか？
0252NAME IS NULL
2014/10/11(土) 18:36:30.46ID:cm1FUS8Zありません。
しゃいん と 打ち込んで 「社員」を候補から選択するために エンターキー を押すと
消えてしまう状態です。
>pi@MOMONGA:~$ あ
>あ: コマンドが見つかりません
と言う風にコンソールに日本語を打ち込むことはできます。
ところが
>pi@MOMONGA:~$ su - postgres
>パスワード:
>postgres@MOMONGA:~$ psql
>psql (9.3.5)
>Type "help" for help.
>
>postgres=#
で、ここから日本語を受け付けてくれなくなるのです。
0253NAME IS NULL
2014/10/11(土) 18:41:02.69ID:???psql -n
の-nオプションつけないといけないみたいです。
ありがとうござますた
0254NAME IS NULL
2014/10/12(日) 20:40:18.38ID:VGIzQpafPostgreSQLにC言語でアクセスしたいと思っています
PostgreSQLは、
apt-get install postgresql
で入れただけです。
ライブラリは、下のように入っているようです。
root@pi:~# aptitude search libpq
略
p libpq-dev - header files for libpq5 (PostgreSQL library)
i A libpq5 - PostgreSQL C client library
p libpq5:i386 - PostgreSQL C client library
p libpqxx-3.1 - C++ library to connect to PostgreSQL
略
そこで、ヘッダファイルを検索すると
root@pi:~# find / -name "postgres.h"
root@pi:~#
のように入っていないようです。
ヘッダファイルは、どのパッケージを入れればついてくるのでしょうか？
0255NAME IS NULL
2014/10/12(日) 21:12:08.53ID:???0256NAME IS NULL
2014/10/12(日) 21:42:20.95ID:VGIzQpafありがとうございます。
apt-get install libpq-dev
をやってみましたが、
root@pi:~# find / -name "postgres.h"
root@pi:~#
と見つからずでした。
root@pi:/usr/include/postgresql# ls
internal libpq libpq-events.h libpq-fe.h pg_config.h pg_config_ext.h pg_config_manual.h pg_config_os.h postgres_ext.h
root@pi:/usr/include/postgresql# ls libpq
libpq-fs.h
root@pi:/usr/include/postgresql# ls internal/
c.h libpq libpq-int.h port.h postgres_fe.h pqexpbuffer.h
というヘッダファイルは作成されました。ですが、postgres.hは見つかりません。
0257NAME IS NULL
2014/10/12(日) 22:10:12.47ID:???libpq-fe.h pg_config_ext.h
があれば、なんとか動くサンプルプログラムだったので、動きました。
postgres.hが必要になって、わからなければまた来ます。
0258NAME IS NULL
2014/10/12(日) 22:41:14.61ID:???0259NAME IS NULL
2014/10/12(日) 22:48:47.90ID:???ありがとうございます！
入ってました！
0260NAME IS NULL
2014/10/13(月) 09:52:46.25ID:z4bUQw3Hを実行してインストールしました。
その後、データベースのデータディレクトリを変更するため
/var/postgresql/data
を作成し、 オーナーを postgres に変更しました。
その後、[postgresql.conf]を
#data_directory = '/var/lib/postgresql/9.3/main' # use data in a$
data_directory = '/var/postgresql/data'
のように変更しました。その後、
export LANG=ja_JP.UTF-8
locale
を実行し、日本語環境にしました。
データベース環境を作成するために
/usr/lib/postgresql/9.3/bin/initdb --encoding='UTF8' -D /var/postgresql/data
を実行しました。その後、initdbの実行後に表示される「こうやれば起動するよ」的なメッセージ通りに
/usr/lib/postgresql/9.3/bin/postgres -D /var/postgresql/data
を実行しようとするとエラーが発生し、すでに起動中であることがわかったので、
ps -ef | grep postgres
kill プロセスID
を実行して、強制的に落としました。再び
/usr/lib/postgresql/9.3/bin/postgres -D /var/postgresql/data
を実行するとキチンと立ち上がります。
そのあと、postgresユーザーでpsqlで入って、
ユーザー：testuser、データベース：testdb、testdbの「オーナー：testuser
を作成して、psql -U testuser -d testdb -n で入ると入れます。selectやinsertでデータ操作も可能です。
しかし、その後マシンを再起動すると、
psql -U testuser -d testdb -n
で入れず、起動中のPostgresqlサービスを
ps -ef | grep postgres
kill プロセスID
で、強制的に落として、再び
/usr/lib/postgresql/9.3/bin/postgres -D /var/postgresql/data
を実行すると
psql -U testuser -d testdb -n
で入れるようになります。
これは、古いデータベースが起動してしまっているのでしょうか？でもpsql \lで見るとtestdbが存在します。
つまりデータフォルダは新規に作成したほうを見ていると思われるのですが・・・。
どこか他に変更すべき設定はあるのでしょうか？
0261NAME IS NULL
2014/10/13(月) 10:19:46.56ID:???postgresql.confのデフォルトのデータディレクトリが
/var/lib/postgresql/9.3/main
などになっているとしたら、
postgresql.conf以外に、起動処理のデフォルトのディレクトリ指定を合わせて変更する必要がある。
Ubuntuはくわしいないけど、もしUpstartで起動処理が構成されているなら、
/etc/init.d/
などにその設定があるかもしれない。
0262261
2014/10/13(月) 10:25:44.15ID:???ちょっとしらべたけどUpstartの起動の設定は、
/etc/init.d/
じゃなさそう。
0263NAME IS NULL
2014/10/13(月) 11:00:08.64ID:z4bUQw3H起動処理があやしいので
[start.conf]を
manual
にして、マシンを再起動したらPostgreSQLは起動せず。
当然psqlは接続できず。
そこで
pg_ctl -w start -D /var/postgresql/data
をしたら起動。
psql -U testuser -d testdb
で接続できました。
やっぱり、マシンリブート後の初期の起動がおかしいようです。
0264NAME IS NULL
2014/10/13(月) 11:03:48.48ID:z4bUQw3H思い切って、
rm -rf /var/lib/postgresql/9.3/main
を実行。その後、[start.conf]を
auto
にしてマシンを再起動。
psql -l
でやってみると、やっぱり testdb がキチンと検出されているので、
/var/lib/postgresql/9.3/main
は、影響していないと思う状態です。
でも
psql -U testuser -d testdb
は入れない。
0265NAME IS NULL
2014/10/13(月) 15:01:01.34ID:???0266NAME IS NULL
2014/10/13(月) 15:05:12.89ID:???0267NAME IS NULL
2014/10/13(月) 15:05:56.16ID:???これを消してみただけです。
0268NAME IS NULL
2014/10/13(月) 15:10:25.95ID:???ついでに、postgresql.confでデータディレクトリ指定するよりは環境変数からの自動認識が無難だと思う
0269NAME IS NULL
2014/10/13(月) 16:12:30.17ID:z4bUQw3Hすっからかんです。
echo $PGDATA
でなんにも表示されません。
ここのセッティングは私も気になっていたのですが、
手動で
export PGDATA="/var/postgresql/data"
として、
initdb
とか
pg_ctl -w start
とかが、できるようになったのが確認できただけです。
PGDATA
に値を入れるとしても、どこで設定すればいいのかがわかりません。
OSから全部まっさらにして、再度インストールを開始してみます。
・・・同じ結果だと思うけど。２回目なので。
あ、インストール前に
export PGDATA="/var/postgresql/data"
にしてみたら・・・。
それでOKならデータの位置を変えるたびに再インストール。頭の良い連中がそんな設計にするわけないか・・・。
0270NAME IS NULL
2014/10/13(月) 16:13:15.28ID:???initdb
pg_ctl -w start
で-Dオプションが不要になっただけです。
0271NAME IS NULL
2014/10/13(月) 16:26:30.97ID:???いちいち指定でいいじゃない
今の問題は何なの、再起動時の挙動だけ？
0272NAME IS NULL
2014/10/13(月) 16:28:38.21ID:???>>264の状態だと意図したとおりのデータディレクトリを参照した状態で起動してるけど、
接続はできないんだよね。
レスのたびに状態が変わってると思うんだけど、切り分けできてる？
あとシステムが汚れてきたのでOSごと再インストールと書いてるけれど、
システムが汚れたという判断はどうやってしたの？汚れてないと思うんだけど。
0273NAME IS NULL
2014/10/13(月) 16:39:12.01ID:???データ領域はその起動スクリプトの中を参照
0274NAME IS NULL
2014/10/13(月) 16:56:49.04ID:???今度は、インストール後
そのままだと、ロケーション等がCになっているので、
pg_ctl -w stop -D /var/lib/postgresql/9.3/main
で終了させた後、
rm -rf /var/lib/postgresql/9.3/main/*
export LANG=ja_JP.UTF-8
を実行した後
initdb --encoding='UTF8' -D /var/lib/postgresql/9.3/main
pg_ctl -w stop -D /var/lib/postgresql/9.3/main
pg_ctl -w start -D /var/lib/postgresql/9.3/main
とした後、
createuser testuser
を実行し、postgresユーザーで
psql
で入った後
create database testdb owner testuser
として、マシンを再起動。
やはり、
psql -U testuser -d testdb
で入れず、
pg_ctl -w stop -D /var/lib/postgresql/9.3/main
pg_ctl -w start -D /var/lib/postgresql/9.3/main
した後、
psql -U testuser -d testdb
で入れる。という状況でした。
再び、再起動すると、やはり、
psql -U testuser -d testdb
で入れない。
もちろん、本番で使うときはそんな頻繁に再起動しないから手動stop、startすればいいんですけど、
なぜ最初から
psql -U testuser -d testdb
で入れないのか謎のままです。
0275274
2014/10/13(月) 16:58:38.50ID:???今回はデータの位置を変えずにやってみました。
新しくユーザーを作成するたびに、PostgreSQLサービスの再起動ってをしないといけないのか？？？
0276NAME IS NULL
2014/10/13(月) 17:07:27.12ID:???うーん。もうほっときます。これは。２日悩んだけど、ちょっとわからない。
init.dのほうなんだろうけど・・。
お騒がせしました。
0277NAME IS NULL
2014/10/13(月) 17:07:28.15ID:???とか無いかい？
0278NAME IS NULL
2014/10/13(月) 17:15:56.63ID:???0279NAME IS NULL
2014/10/13(月) 18:08:33.90ID:???状況の気持ち悪さは理解できたけど、この結論に至る理由はきわめて謎。
念のためだけど、psql -U testuser でもダメなのかな。
ログを見るとか、-p 5432を付けてみるとか、切り分けるべき情報はいくつかあると思うよ。
0280NAME IS NULL
2014/10/14(火) 18:29:19.65ID:gaPuhb7/0281NAME IS NULL
2014/10/14(火) 18:51:00.41ID:???例えば「1回のトランザクションで全件更新」みたいな処理があると
オートバキュームだけでは最高効率を保てないこともある。
まぁ、そもそも最高効率を維持する必要がないほどガバガバの設計にして、オートに任せるのが楽だけど。
0282NAME IS NULL
2014/10/15(水) 15:47:17.31ID:???Windows XPにPostgresql9.2をインストールしてるんですが
Windows 7のクライアントからtelnet サーバーのhostIP 5432
で接続されません。
なぜかXPのクライアントからは接続できます。
ファイアウォールは一時的にサーバーもクライアントも無効にしてみました。
pg_hba.confには
host all all 10.0.0.0/8 trust
も追加しました。
なぜなのでしょう。お手上げですorz
0283NAME IS NULL
2014/10/15(水) 16:15:31.00ID:???localhostでしかlistenしてないとか
0284NAME IS NULL
2014/10/15(水) 16:31:24.69ID:???ローカルからlocalhostではなく、外向きのIPアドレスでも確認した方がいいよ
デフォルトだと、postgresql.conf のlisten addressはコメントの上に localhost になってると思うから
コメント外して '*' にするといいよ。
0285NAME IS NULL
2014/10/15(水) 16:46:38.11ID:???そもそもpingの応答もないですorz
これではだめですね。すみませんでした。一旦取り下げます。
0286NAME IS NULL
2014/10/15(水) 21:41:50.51ID:???ルーティング
そんなところかな？
0287NAME IS NULL
2014/10/15(水) 21:51:18.35ID:???ウィルスバスターを落としたら接続できました。
0288NAME IS NULL
2014/10/15(水) 22:30:09.02ID:???0289NAME IS NULL
2014/10/15(水) 22:43:52.74ID:???そのエンコード変換には対応していないから。ぐぐれば理由も対処法もすぐ見つかる。
0290NAME IS NULL
2014/10/15(水) 22:54:19.82ID:???申し訳ないです、ありがとう。
0291NAME IS NULL
2014/10/15(水) 23:04:49.84ID:???euc-jpはてきとーな実装がたくさんあったんだろうな。
で、整理される前に、そもそもEUCが使われなくなって放置された、と。
0292NAME IS NULL
2014/10/23(木) 14:10:39.99ID:???0293NAME IS NULL
2014/10/23(木) 19:20:44.76ID:???0294NAME IS NULL
2014/10/23(木) 19:48:59.96ID:???SQLコマンド別ならドキュメントにもあるけど
0295NAME IS NULL
2014/11/12(水) 09:30:14.21ID:fMuaBpeN0296NAME IS NULL
2014/11/12(水) 09:30:55.47ID:fMuaBpeNpsqlで、\hね
0297NAME IS NULL
2014/11/12(水) 11:11:08.60ID:???右クリックで、
データビュー、全ての列を表示
データ編集のウィンドウのグリッドが表示されるが、
そこで、ある１行の列の値を編集すると、
たくさんの他の行まで、その値に勝手に変わってしまう恐ろしいバグを発見。
pgAdmin でデータの編集、変更はしないほうがいいな。
SQLのUPDATE文で変更した。
0298NAME IS NULL
2014/11/12(水) 11:24:05.47ID:???0299NAME IS NULL
2014/11/12(水) 17:22:59.79ID:???0300NAME IS NULL
2014/11/12(水) 19:44:51.15ID:???＞キーがないって警告出なかった？
出なかった。
Keyは設定しています。特殊なやり方だけど。
その特殊なKeyが原因なんだろうな。
注意しよう。
でも致命的なバグは解消してもらいたいものだ。
0301NAME IS NULL
2014/11/12(水) 19:53:08.55ID:???自分で特殊特殊言ってて、致命的なバグと断定するのは如何なものか
第三者には「とにかく俺は悪くないけどあいつが悪い」と言ってるだけにしか見えない
その特殊な例とやらを披露してみれば？
0302NAME IS NULL
2014/11/12(水) 19:59:17.80ID:???特殊なキーってどういうの？
0303NAME IS NULL
2014/11/12(水) 22:49:17.12ID:???oid をキー。
推奨はされていないが可能。
特殊でもないと言えば、特殊でもない。
レコード数は数万程度しかないので、論理的には問題ないはず。
0304NAME IS NULL
2014/11/13(木) 00:18:55.67ID:???0305NAME IS NULL
2014/11/13(木) 08:48:35.90ID:???じゃ、oidが原因ではないなら、
別な原因ですかね。
再現性があるとは限らないので、複合的要因もあるかもしれないですが。
しかし致命的すぎる。
前からそうだけど、
pgAdminのデータ編集グリッドで修正、更新すると
アプリエラーで落ちること多いし。
ちなみに、DBもpgAdminもWindows版です。
0306NAME IS NULL
2014/11/13(木) 10:57:08.32ID:???（運用始まったらめったにやらんけど、開発中とトラブル対応は、ね）
問題出たこと無いなあ、まあ気をつけたいけどどう気をつけたらいいのやら。
まあ最近のは落ちること多いかな、ssh介して切れること多いと特になあ。
0307NAME IS NULL
2014/11/13(木) 11:43:49.78ID:???無難なdate, to_dateし易いchar, 結構ありがちと思われるint ？？
よかったら理由も教えて下さい。
あと過去スレ漁ろうと思ったんだけど、テンプレのPostgreSQL Part.8、 Part.9 以外切れてました。外してもよさそう。
0308NAME IS NULL
2014/11/13(木) 11:45:18.48ID:???>問題出たこと無いなあ、まあ気をつけたいけどどう気をつけたらいいのやら。
とりあえず、修正前にDBやテーブルのバックアップだね。
問題出たことないなら、気にしないでいいけど、
いつ出るかわからないからね。
他のレコードのその列の値がいっせいに変わってしまうから、
バックアップもなく復旧できなかったら、致命的。
自分も数年、今までそんな致命的な問題はなかったから、びっくりした。
それと、初めて、サービスでPosgreSQL ver8 が起動しなかったから、
再インストールしてバックアップからリストアした。
最近使っているのは、ver9だけど、
古いver8のシステムは、バージョンアップせずそのまま。
0309NAME IS NULL
2014/11/13(木) 11:55:17.93ID:???＞皆さん年月ってどのデータ型使ってますか？
＞無難なdate, to_dateし易いchar, 結構ありがちと思われるint ？？
最初の頃は、char で作ってたけど、おそらく検索が遅くなるから、
レコード数が数十万、数百万以上になるようなら、
timestamp , date ,time を使った方がいいのでは。
検索速度のテストでどのくらい違うかはわからないから確証はない単なる憶測。
0310308
2014/11/13(木) 12:01:51.71ID:???＞それと、初めて、サービスでPosgreSQL ver8 が起動しなかったから、
ver8ではなくて、ver9がWin7で起動しなくなった。約2年後くらいかな。
DBが止まると業務に支障が出るから大変だね。
業務の内容によっては、
レプリケーション、待機サーバも検討したほうがいいかも。
PostgreSQL ver9のレプリケーションは、設定が面倒なんだよな。
0311NAME IS NULL
2014/11/13(木) 12:57:57.46ID:???postgresqlとpgadminのバージョンは適したものを使ってる？
0312NAME IS NULL
2014/11/13(木) 17:28:28.99ID:???計算しないものに関してはyyyymmddのintだったり
基本的にはDate,Timestamp型使うけどnull許容だと取り出したあとのチェックが
面倒だったりするんだよなあ
0313NAME IS NULL
2014/11/13(木) 22:41:02.29ID:???クライアント OS で業務に使う DB 動かしてる分際で、待機サーバー云々とかアホすぎる w
0314NAME IS NULL
2014/11/14(金) 00:45:15.68ID:???ミリ秒やμ秒を扱ったり、カレンダー由来、HTTP時刻などの文字列由来なら timestamp型
timestamp型はWHERE句が単独条件ならいいんだけど複合条件になった時に
複合インデックスを張っても使ってくれなかったりBitmapAnd や BitmapOr にならずに
Filter: に追い出されたりしやすい傾向があるような気がちょっとだけするので
あまり好きじゃない。
0315NAME IS NULL
2014/11/14(金) 01:02:46.31ID:???0316NAME IS NULL
2014/11/14(金) 01:53:50.00ID:???分かるわー
0317NAME IS NULL
2014/11/14(金) 02:02:00.67ID:???0318NAME IS NULL
2014/11/14(金) 02:21:20.01ID:???0319NAME IS NULL
2014/11/14(金) 10:15:05.21ID:???で、"00000000"とか"99999999"とか入れちゃう奴が出てくるんだよ。
0320NAME IS NULL
2014/11/14(金) 12:59:59.63ID:???24時間以上、365日以上、連続稼動しないなら、
クライアントOSでも十分だけど。
わざわざ、Windows Serverを買うほうが、バカらしいよ。
サーバ1台より、
クライアント2台で待機サーバーや予備サーバを準備していたほうが、
業務としては安心。
サーバ1台、こけたら、終わりじゃん。
0321NAME IS NULL
2014/11/14(金) 13:37:03.44ID:???0322NAME IS NULL
2014/11/14(金) 13:38:38.22ID:???ライセンス違反って知ってるか
0323NAME IS NULL
2014/11/14(金) 13:47:43.45ID:???0324307
2014/11/14(金) 14:04:24.58ID:???ちなみに俺は年月日はdate一択です。
0325NAME IS NULL
2014/11/14(金) 16:37:51.67ID:???知らないのは、あなたのようだね。
0326NAME IS NULL
2014/11/14(金) 16:39:45.10ID:???サーバ2台ならより安心だけど、
高いハード、高いOSを導入するほど、その必要性はない。
0327NAME IS NULL
2014/11/14(金) 16:46:33.52ID:???年月も同じことでしょ。
日付型を利用するなら、yyyymm01で格納したらよい。
大量のデータにならないなら、char で'yyyymm'でも別に構わないと思うよ。
それほど気にする必要もない。
0328NAME IS NULL
2014/11/14(金) 17:02:02.09ID:???CREATE DOMAIN month AS integer CHECK (...)
とかしてたら惚れる。そんなシステム見たことないけど。
0329NAME IS NULL
2014/11/14(金) 19:48:43.27ID:???計算ないんだから問題なし
DATE型変数で読んでたら単にバカだぞ
0330NAME IS NULL
2014/11/14(金) 22:33:59.68ID:???0331NAME IS NULL
2014/11/14(金) 22:57:25.57ID:???> 24時間以上、365日以上、
なにを言いたいのかさっぱりわからん w
0332NAME IS NULL
2014/11/14(金) 23:01:45.08ID:???で、いざ計算するはめになったら 2014/11/31 とかが出てきて大慌てするんですね w
まあ、うちのことだか... orz
0333NAME IS NULL
2014/11/15(土) 00:00:48.18ID:???普通に再起動する。
0334NAME IS NULL
2014/11/15(土) 03:09:55.89ID:???0335NAME IS NULL
2014/11/15(土) 04:28:06.56ID:???0336NAME IS NULL
2014/11/15(土) 08:52:31.26ID:???計算しない前提での話に対して
計算することになったらって意味あるの？
0337NAME IS NULL
2014/11/15(土) 08:54:07.49ID:???11月31日って日付計算も出来ないバカだから
DBにお任せかよ
0338NAME IS NULL
2014/11/15(土) 08:56:32.82ID:cs4K00+DWinXP/7/8とWinServerを比較しても、大差ない。
CPUの性能程度の差。
数百以上などたくさんの同時アクセスの業務でもないし。
もしサーバ用PC(クライアントOS)が壊れても、
DBのバックアップさえとっていれば、
他のクライアントPCを代替DBサーバに簡単に置き換えらえるので便利。
0339NAME IS NULL
2014/11/15(土) 11:04:45.90ID:???0340NAME IS NULL
2014/11/15(土) 12:41:04.94ID:???その程度の仕様変更はいくらでもあるだろ
>>337
日付計算？
0341NAME IS NULL
2014/11/15(土) 12:43:32.18ID:???バックアップで復旧とか言ってるぐらいだし、あんまり苛めてやるなよ w
0342NAME IS NULL
2014/11/15(土) 17:04:46.27ID:???ここ10年ぐらいはいつでも好きなときに再起動してるけどなぁ。
それより前ぐらいは止められないシステムがあったが、ばかげてるよね
0343NAME IS NULL
2014/11/15(土) 19:57:53.71ID:???前提を無視して仕様変更かよ
0344NAME IS NULL
2014/11/15(土) 20:29:25.08ID:???そうだよ、経験したことないのか？
0345NAME IS NULL
2014/11/15(土) 20:46:05.64ID:???バカ丸出し
0346NAME IS NULL
2014/11/15(土) 21:03:45.94ID:???客商売したことないのか？
0347NAME IS NULL
2014/11/15(土) 21:27:09.38ID:???人と会話したこと無いのか？
聞いたことに対して聞かれていない事への返事してどうするんだ
0348NAME IS NULL
2014/11/15(土) 21:51:59.20ID:???実際マジで羨ましい。
うちは1回立ち上げたら数年は深刻な理由がないと落とせないし、止めるときも深夜の数時間ぐらいしか止めれないから準備がマジで大変。
無停止の非機能要件があることはともかく、それをポスグレを落とさないアーキテクチャで実現しようとするの馬鹿げてる。
0349NAME IS NULL
2014/11/15(土) 22:11:15.49ID:???スレの流れも追えないんなら、いちいち絡んでくるなよ...
0350NAME IS NULL
2014/11/15(土) 22:15:52.46ID:???> うちは1回立ち上げたら数年は深刻な理由がないと落とせないし
そんなシビアなシステムならホットスタンバイぐらいしてるだろ
訓練兼ねて月１ぐらいで切り替えやってるだろうし
してないなら、単に SE がバカなだけ
0351NAME IS NULL
2014/11/15(土) 22:26:07.03ID:???自分は絶対に正しいって奴か
すっげー偉いね坊や
0352NAME IS NULL
2014/11/15(土) 22:35:02.96ID:???他に
> うちは1回立ち上げたら数年は深刻な理由がないと落とせない
の要件を満足させる方法があるなら教えてくれよ w
0353342
2014/11/16(日) 00:23:27.32ID:???えーっと、たとえばマザーボード壊れたらどうするの？
サービスをとめてはいけないなんてのは今どき普通で
それでも再起動が必要になることはあるんだから両立させるってことだよ？
0354NAME IS NULL
2014/11/16(日) 00:29:09.14ID:???どの流れだ？
話が全く違うぞ
0355NAME IS NULL
2014/11/16(日) 03:14:37.42ID:???スタンバイしてるんなら問題ないと思うが。
フェイルオーバーのテストにもなるしw ｵｲｵｲ
0356NAME IS NULL
2014/11/16(日) 03:46:44.40ID:???>>351が自分(>>350)へのレスだと思ったんだろう。
ばかだよねー。そそっかしすぎてシステム任せらんない
0357NAME IS NULL
2014/11/16(日) 08:53:41.49ID:???ホットスタンバイあるし切り替え手順もあるけど、数秒のサービス断が発生するしアプリの再起動も煩雑だから毎月の訓練とかはして無いんだよ。
で、待機系に切り替える心理的障壁が高くなってなるべくマスターだけで何とかしようとなってしまってる。
悪循環だなぁとは思ってるけどね。
簡単にマスタ・スレーブをアプリから見て気づかないように切り替えれる仕組みを作りたい。
0358NAME IS NULL
2014/11/16(日) 09:24:37.91ID:???> 数秒のサービス断が発生するしアプリの再起動も煩雑だから
見てて痛々しいからもうやめたら？
0359NAME IS NULL
2014/11/16(日) 10:32:31.28ID:???0360NAME IS NULL
2014/11/16(日) 11:38:41.80ID:???0361NAME IS NULL
2014/11/16(日) 13:51:30.96ID:???なんでそんなことするかなあ、バカじゃないの？
ちゃんと SMALLINT にしろよ、もったいないだろ
0362NAME IS NULL
2014/11/16(日) 14:41:06.69ID:???0363NAME IS NULL
2014/11/16(日) 15:59:07.98ID:???いいと思うよ。
俺はdateだけど。
0364NAME IS NULL
2014/11/16(日) 16:11:40.07ID:???0365NAME IS NULL
2014/11/16(日) 16:59:00.85ID:???0366NAME IS NULL
2014/11/16(日) 18:30:14.25ID:???Postgresの売りは、text型の優秀さだろ？
0367NAME IS NULL
2014/11/17(月) 11:31:40.76ID:???年月でユニークにしたいときに日付が入るとユニークにならなくなる問題はあるな
0368307
2014/11/19(水) 14:12:43.59ID:???dateは後ろに01が付くのが気持ち悪いし、intはdateとの比較するとき変換が多くなるし、
年月分けたら比較とか面倒だし、、、charにしようかな。
大小比較とかで見えないコストが増えそうだけど。。
0369NAME IS NULL
2014/11/19(水) 14:14:01.89ID:???varchar(20)とvarchar(24)は一緒だよとか。varchar(25)とvarchar(24)では1文字以上の節約だよとか。
UNICODEなんで内部的には2バイトだろうし、あんまり関係なさそうな気もしますが（あくまで予想）。
0370NAME IS NULL
2014/11/19(水) 16:07:58.11ID:???長い文字列を投入したときDBでエラーにしたければ、その文字数を指定すれば良い。
格納効率だけなら text, varchar(N), varchar (長さ指定無し) は全て同じ。
あと、UNICODE は 内部的には UTF-8。
日本語1文字は3バイトになるから、貧乏性だともったいなく感じるかも。
0371NAME IS NULL
2014/11/19(水) 16:27:58.24ID:???コード(CAT222みたいなやつ)を格納できるASCIIだけのデータ型が欲しいなあ。
0372NAME IS NULL
2014/11/19(水) 16:37:59.83ID:???あらかじめコードの種類が決まっているならENUM型でも良いし。
0373NAME IS NULL
2014/11/19(水) 16:50:51.37ID:???OCTET_LENGTHで見てみるとASCIIは１文字１バイトですが、
これがそのまま利用されているバイト数と考えていいんですか？
長い日本語文字列をINSERT → 日本語消して短いアルファベット文字列でUPDATE
この時は、消した分の領域は空くことになるんでしょうか？
0374NAME IS NULL
2014/11/19(水) 16:56:14.16ID:???DELETEもフラグつけるだけ。
VACUUM時に整理される。
0375NAME IS NULL
2014/11/19(水) 16:58:52.68ID:???それって行単位だよね？
だから、373のパターンの空きは空きのままじゃないかな？
また増えたときのあふれ領域代わりになるし。
0376NAME IS NULL
2014/11/19(水) 17:16:27.39ID:???あくまでも文字数だよ。 ASCII 1文字なら 長さ+文字 で2バイトだとは思うが。
>>374 のとおり、UPDATEされた行全体がゴミになって、しばらくは空いたままだが、
VACUUM後のINSERTかUPDATEで、ゴミのサイズ以下の行が作られる場合に再利用される。
だから、更新でのサイズ増加を見越して行単位で隙間を持たせるのは無駄。
ページ単位での隙間なら、役に立つ場合もある。
0377NAME IS NULL
2014/11/19(水) 17:57:24.90ID:???VACUUM FULL したら容量減った。ちなみにただのVACUUMだと変化なしだった。
>>373の１つ目は調べようがないな（スキル的な意味で）
0378NAME IS NULL
2014/11/19(水) 19:11:42.43ID:???>>373は、
行の中の列の話なんじゃないの？
0379NAME IS NULL
2014/11/19(水) 19:29:55.96ID:???行の中の列にだけ隙間があるってどういう状態なんだよ？
特定のフィールドのみを上書き更新なんてできないぞ？
0380NAME IS NULL
2014/11/19(水) 20:34:19.07ID:???0381NAME IS NULL
2014/11/20(木) 10:19:07.43ID:???そもそもRDBMSって内部キニシナイで使えるのがいいんじゃないの？
もちろんシビアな条件のチューニングには必要だろうけど。
内部を深く知りたいやつはソース読めばいいんだし、
普通に使ってる分には「時々VACUUM FULL 必要」ってだけでｲﾝｼﾞｬﾈ？
0382NAME IS NULL
2014/11/20(木) 11:23:30.79ID:???理由は、既存のソフトが機能拡張拡張・・でいつの間にか月に１０Mずつ増えて、
月のバックアップが１０G超えるレベルになってきたんですよ。
今回リプレースにあたって、DBの設計から出来るので、見直せるところは見直そうかなと思いまして。
PostgreSQLを業務利用するの初めてなので、試行錯誤中という感じです。
とりあえず「VACUUM FULLが必要」と「booleanよりbit」というのが今のところ効果が大きそうだなと思っています。
0383NAME IS NULL
2014/11/20(木) 13:50:45.46ID:???0384NAME IS NULL
2014/11/20(木) 20:55:22.32ID:???> もちろんシビアな条件のチューニングには必要だろうけど。
こういうの見ると時代は変わったのかなぁって思う。
シビアでもなんでもないけど、レコード長を気にしながら設計してたのは今は昔か。
ところで、ひどいレスがついているんで、これだけは言わせて欲しい。
>>382 vacuum fullは使うな。auto vacuumでいい。
0385NAME IS NULL
2014/11/20(木) 21:43:47.23ID:???なんでvacuum fullダメなん？
暇ならやってもいいんじゃないの？
0386NAME IS NULL
2014/11/20(木) 21:48:56.34ID:???暇ならやってもいいんじゃない？って程度なら、やってはいけない。
適した用途は極めて限定的なので、まずは使わないということで割り切っていいよ。
0387NAME IS NULL
2014/11/20(木) 21:52:08.56ID:???ただ、「デフラグ」ではなく「作り直し」だから、それなりに重い処理ではある。
それだけの価値があるかは状態次第だが、本当に暇ならやっても良いと思うよ。
0388NAME IS NULL
2014/11/20(木) 21:55:21.11ID:???それを必要とする場面が極めて少ないことには変わりないよ。
autovacuumが正しく動作しているかどうかの確認が先決。
そして「大抵は」それで問題がない。
0389NAME IS NULL
2014/11/20(木) 22:20:39.85ID:???効果有りだと思ってる。
0390NAME IS NULL
2014/11/20(木) 22:55:08.49ID:???最初にデータが入って全行激しく更新されたあと、更新が途絶えるってケース以外はauto vacuum任せでもだいたい問題ない。
auto vacuumがおいつかないという地獄のケースもあるが、そういうときはプロセス数を増やすしかないな。
0391NAME IS NULL
2014/11/20(木) 23:41:30.67ID:???そうやって更新回数を増やして寿命を縮めるのが趣味なの？
0392NAME IS NULL
2014/11/21(金) 10:55:42.38ID:???text型を使うようなテーブルはVACUUM FULLしておいた方がいいんじゃないの？
もちろん毎回じゃなくてもいいが、状況によって週一とか月一とか。
>「デフラグ」ではなく「作り直し」だから、
この表現分かりやすいね。ありがと。
0393NAME IS NULL
2014/11/21(金) 15:31:20.02ID:???> text型を使うようなテーブルはVACUUM FULLしておいた方がいいんじゃないの？
理由は？
> もちろん毎回じゃなくてもいいが、状況によって週一とか月一とか。
毎回じゃなくてもいいが週一っていうのは、
もし「毎回」しようと思った場合はどのくらいの頻度でvacuum fullするの？
0394NAME IS NULL
2014/11/21(金) 15:52:37.28ID:???0395NAME IS NULL
2014/11/21(金) 16:10:18.21ID:???> 理由は、既存のソフトが機能拡張拡張・・でいつの間にか月に１０Mずつ増えて、
> 月のバックアップが１０G超えるレベルになってきたんですよ。
ひょっとして、dailyでコールドバックアップを取って、永久保存したりしてのか？
だとしても、ディスク容量が1TBあれば10年弱は戦える。
だけどディスク容量が問題なら、バックアップ方式を見直すべきなんじゃないの？
0396381
2014/11/21(金) 16:25:04.01ID:???>>384
N-88とか使ってた頃はデータサイズにシビアに拘ってたな。
でもさ、せっかく楽できるようにRDBMS使い始めても、
こまけぇことに拘ってたら手間隙余分にかかるだけだろ。
手続き型だって、プロセッサパワーでゴリ押し出来るようになったんだから、
回数多く回るループだけチューニングとかでそこそこ何とかなる。
ギークなら仕方ないがPGやSEはこまけぇことに拘らず自動化出来る所は自動化し、
ライブラリ使える所は使い、仕事をこなせばインジャネ？
Sヨだとチューニングすら出来ないほどヘッポコな事やりそうだがｗ
0397NAME IS NULL
2014/11/21(金) 16:56:39.40ID:???>ひょっとして、dailyでコールドバックアップを取って、永久保存したりしてのか？
永久では無いですが、その通りです。復旧時とか焦ってる時に差分バックアップから復元は僕には困難だと思ったので。
>だとしても、ディスク容量が1TBあれば10年弱は戦える。
僕もそのくらいの軽い気持ちだったんですけど、月に10M増えるのは馬鹿に出来ないんですよ。
デイリーなので、翌月には300M増えるんですね。つまり３ヶ月で1Gずつ毎月のバックアップの量が増えるんですよ。
サラ金ってこんな感じなのかもって思うくらい、すげー勢いで増えていくんですよ。
0398NAME IS NULL
2014/11/21(金) 17:08:52.85ID:???実際に復旧したことある？
dailyバックアップってことは、最新のバックアップから現在までのトランザクションが
全て失われるってことなんだけど。
まあそれでいいとして、ディスク容量が問題なら、VACUUMとかの小手先の方法じゃなくて、
抜本的な改革が必要じゃないかな。たとえば、
・圧縮を使ってないのなら圧縮する
・古いものは間引いて捨てる
・古いものは別ディスクに移動する
・バックアップ方式を変更する（WALを利用したオンラインバックアップ）
おすすめは四つ目だけどね。
0399NAME IS NULL
2014/11/21(金) 17:53:32.57ID:???10日で1割増えるのならサラ金の感覚だけど、それに比べりゃ全然優しいもんでしょ。
デイリーバックアップが復旧に十分な機能を果たすのであれば >>398 の2でいいと思うよ
0400NAME IS NULL
2014/11/21(金) 17:57:30.45ID:???理由は>>377
>>398
運用中に復旧は経験ないです。今回も夜中２，３時間止めても問題ないようなシステムですのでその辺の心配はないかな。
なので毎日VACUUM FULLでもいいかなと思ってたんですが、皆さんのレス見る限り必要なさそうですね。
デッドタプル率が高ければFULLかけるようなデーモン作れれば良さそうですけどね。出来るか分かりませんが。
0401NAME IS NULL
2014/11/21(金) 18:27:18.22ID:???> 運用中に復旧は経験ないです。
バックアップ計画に切実さがないんじゃないかな。
とりあえず全部保存しとけみたいな。
どんなシステムなのかわからないけど、実際に問題が発生したときにどのバックアップセットが
必要になるのかをよく考えれば、
>>399も言ってるように
> ・古いものは間引いて捨てる
でいい気がする。
・直近1ヶ月はdailyで
・それ以前の1年まではweeklyで
・それ以前はmonthlyで
みたいな感じで残す程度でいいんじゃないの？
0402NAME IS NULL
2014/11/21(金) 19:29:38.22ID:???レンタルサーバ上にシステム作って、そこがそんなに容量ないからデータサイズとかVACUUMとかでなるべく運用中に容量増えないようにしたい。
レンタルサーバ上は１ヶ月分残して、毎日社内のサーバにバックアップ。
２ヶ月分はミラーリングかかる場所ｘ２（別地域）で、それ以上はファイルサーバの奥深く。容量足りなくなったら消しちゃえくらい。
どうせバックアップから復旧しなきゃいけない事態の時は土下座レベルじゃ効かないだろうし、諦めます。
というわけで、気にしているのはレンタルサーバ上の話なんですよね。
0403NAME IS NULL
2014/11/21(金) 21:13:08.72ID:???> >>393
> 理由は>>377
なら使うなって。わからんかなぁ。使うな。
0404NAME IS NULL
2014/11/22(土) 00:18:42.74ID:BTiOZKQh0405NAME IS NULL
2014/11/22(土) 09:42:49.45ID:???http://www.postgresql.org/about/news/1555/
0406NAME IS NULL
2014/11/22(土) 13:13:15.06ID:???0407NAME IS NULL
2014/12/19(金) 17:18:52.92ID:???http://www.postgresql.org/about/news/1557/
0408NAME IS NULL
2014/12/19(金) 19:21:05.44ID:???c言語が死滅しない限りODBCを無くすことは無理だと思う
WindowsではVB6と共に永遠に不滅ですwww
0409NAME IS NULL
2014/12/20(土) 07:37:55.61ID:0pKWV/8B祝9.4リリース！
PGConのキーノートでSimonも言ってたけど、最新版のPostgreSQL、もっと使おうぜ。
0410NAME IS NULL
2014/12/20(土) 10:46:05.45ID:???0411NAME IS NULL
2014/12/20(土) 21:35:50.69ID:AfYrfdbEhttp://fluid.twolineprj.com/twoline/entry
テーマは自由自在。自由に投稿してみてください。
0412NAME IS NULL
2014/12/20(土) 22:05:20.36ID:0pKWV/8Bユーザーサイドでみると目立つのはJSONBくらいかもなあ。
SQL構文の地味な拡張とかもあるにはあるけど。
一部の集約関数の性能改善や、GINインデックスの改善なども地味だけど重要かも。
あと、今回はPostgreSQL開発者向けの基盤拡張というのはある。
あと、ロジカルデコードのフレームを使って面白い拡張機能は作れそう。
0413NAME IS NULL
2014/12/24(水) 22:32:37.23ID:???テーブル内容
コード１ コード２ 内容
１ １ あ
１ ２ い
１１ １ ２
１１ ２ １
欲しい結果
コード１ コード２ 内容
１ ２ い
１ １ あ
コード１＝１は取得したい内容
コード１＝１１は並び順
１と１１が別テーブルなら出来そうだが
0414NAME IS NULL
2014/12/24(水) 23:08:26.12ID:???単純に2回参照して「別のテーブル」扱いすれば良いんじゃないの？
SELECT A.* FROM テーブル内容 AS A, テーブル内容 AS B
WHERE A.コード1 = 1 AND B.コード1 = 11 AND A.コード2 = B.コード2
ORDER BY B.内容
0415NAME IS NULL
2014/12/24(水) 23:36:55.59ID:???そうでした
ありがとう
スレ汚しごめん
0416NAME IS NULL
2014/12/25(木) 03:07:52.43ID:???0417NAME IS NULL
2014/12/25(木) 08:18:38.82ID:???「スキーマ定義は神聖不可侵なものである」という教義を尊重するあまり
最大限の汎用性を持たせようとして万能テーブルを使ったケースかな
PGはオンラインのままでもDDLを発行しやすいほうだから
その特性を知っていれば違う設計になったかもな
0418あ
2014/12/25(木) 19:37:01.69ID:???/:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::://ヽ:::::::::::::::|
l:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::// ヽ::::::::::::::l
l:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::/:::「'ヽ:::::::::::// ヽ:::::::::::|
|::::::::::::::::::::::::::::::::::::::::::::::::::::::::::ﾉl:::ﾉ l:::::::／ ヽ::::::::|
ﾉ:::::::::::::::::::::::::::::::::::::::::::::::::::::／ ﾞﾞ ﾉ:::/ ,,;;;;;;,, ,,,,ヽ:::::l
）:::::::::::::::::::::::::::::::::::::::::::::::／ ノ／ ＿＿,'''i: ('''＿_）:::l
）::::::::::::::::::::::::::::::::::::::::::::::::::/ ￣￣ン:. :「￣`ヾ
1:::::::::::::::::::::::「 ｀┤l:::::::::::::::::l ￣ , ヽ￣ l
｀l:::::::::::::::::::::ヽ :l li:::::::::::::/ ヽ /´ ｀l |
ヽ::::::::::::::::::::::＼_」 lヽ::::／ .l !:-●,__ ノ /
ノ:::::::::::::::::::::::::::ﾉ | l ｀ﾞﾞ i ,,;;;;;;;;;;;;;;;;;;;;, /ヽ
,／ ヽ::::::::::::::::::::::（ l l::::::::.. /.:''／´￣＿ｿ / ｀ヽ
ヽ:::::::::::::::ヽ | l:::::::::::... /::/／￣￣_ソ / ＼ ヴッ！！
ヽ:::::::＼| l::::::::::::::::... / :::.ゝ｀￣￣／ ／ ヽ
ヽ:::l l:::::::::::::::::::.. ￣￣;;'' ／ ヽ
l l;;;;;;:::::::::::::::.....;;;;............;;;;;;''ノ l
l l ''''''''''''''''''''''''''''''''''''''￣l | |
http://www.youtube.com/watch?v=z2qK2lhk9O0
0419NAME IS NULL
2015/01/02(金) 12:56:25.57ID:WZUnVn6u（具体的に言うと一時テーブルが残る）ので悩んでいます。
今のところ別件で知った強制切断の関数を使って、以下のように対応しています。
(new NpgsqlCommand("SELECT pg_terminate_backend(pg_backend_pid())", Db)).ExecuteNonQuery();
Db.Close();
これで一時テーブルは消えましたが、なんとなく標準的な方法じゃないような気がするので、
ご存じの方がいらっしゃったら教えてください。
※各クエリでもDROP TABLEしてますが、エラーハンドリングの標準化として、
何があっても共通関数で一括クリアする二段構えにしたいです。
※CREATE TABLE ASのON COMMITオプションは不便なので、セッション内では永続したいです。
※Db.Dispose()後newから再開してもセッションが残りました。
0420NAME IS NULL
2015/01/02(金) 13:08:52.51ID:???横ですが初級者向けならむしろ１つのテーブルに
項目増やして分類コード消すのが普通かとｗ
コード 内容 並び順
１ あ ２
２ い １
でも人事関連とか全部別テーブルや別項目にすると膨大になり過ぎる
または分類が動的かつ膨大で実質不可能で、
１つの巨大テーブルで分類分けせざるを得ない場合があります。
SAPがそうです。
0421NAME IS NULL
2015/01/04(日) 04:39:11.78ID:???試してないけど、connection を using でくるんでもだめ？
0422NAME IS NULL
2015/01/04(日) 09:06:52.16ID:ckIsqYF1そんなことするくらいなら、contrib/hstoreやjson型でいいのでは？
0423NAME IS NULL
2015/01/04(日) 09:32:47.25ID:???検索しないなら、入力したテキストなりバイト列をそのまま持てば良いのでは。
たまに検索したいこともあるなら、hstore, json, xmlなんかは適するかもね。
0424NAME IS NULL
2015/01/04(日) 18:48:37.53ID:???なにいってんのかよくわかんない
0425NAME IS NULL
2015/01/04(日) 19:58:30.62ID:???動作速度のために、接続はアプリ終了まで保持で、エラー時だけロールバック＆切断し、
次のクエリで再接続してまたアプリ終了まで保持っていうパターンでやってるので、
一発で破棄するusingは使えません
（Dispose()とusingで挙動が違ったら恐いですが…）
0426NAME IS NULL
2015/01/04(日) 22:48:57.83ID:???接続文字列のPoolingはどうなってるの。
0427NAME IS NULL
2015/01/05(月) 21:52:39.57ID:???PostgreSQL文書やJPUGイベントで公開されてる資料とか
見てみるのがいいんじゃないかな？
0428NAME IS NULL
2015/01/06(火) 05:04:31.68ID:???言葉を変えれば、的外れなレスをしてどうするのといっている。
0429NAME IS NULL
2015/01/09(金) 05:13:33.49ID:WNft05J8すいません忙しくてつい忘れてました…
Pooling=FALSE付けたらCloseだけで一時テーブル消えました
ありがとうございました
なるほど、まさに動作速度の問題で裏で接続維持してくれるってことですか
今やってるのWebじゃないので、Pooling=FALSE付けときます
0430NAME IS NULL
2015/01/11(日) 01:23:31.91ID:???他のPCから接続するにはどうすればよいのでしょうか？
postgresql.confのlisten_addressesは最初から*になっていて、
pg_hba.confはall all 0.0.0.0/0 md5を追加して、
ローカルでは168.192.*.*のip指定で接続できるようになりました
iptablesの設定がまだです
コマンドプロンプトで pg_config.exe --sysconfdir とすると
C:\{インストール先}\9.3\etc
と出るのですが、そこにetcフォルダはありません
0431NAME IS NULL
2015/01/11(日) 10:25:17.90ID:???Windows同士のLAN接続だと IPv6 が優先されるから、その設定が必要だった気がする。
0432NAME IS NULL
2015/01/11(日) 20:28:53.47ID:???ありがとうございます
不慣れなもんでもっと低次元な問題でした…
Windowsファイアウォール外したら繋がりましたｗ
（iptablesってPostgreSQL無関係で、Linuxのことだったんですかね？）
0433NAME IS NULL
2015/01/11(日) 20:44:59.89ID:???0434NAME IS NULL
2015/01/20(火) 21:41:33.80ID:acOkIpqZhttp://jbbs.livedoor.jp/bbs/read.cgi/study/3729/1226114724/78
↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑ ↑
この掲示板に優秀な書き込みをして、総額148万円の賞金をゲットしよう！(*^^)v
0435NAME IS NULL
2015/01/21(水) 15:42:57.54ID:7jfTDvH8ターミナルで、
./FETCHTBL.sh
SQLSTATE: 08001
Connection falied
で、エラーになり実行できません。
sudo -u postgres ./FETCHTBL.sh
だと、実行できます。
そこでGRANTでuser01を追加しました
su - postgres
psql testdb
\l では、下の様になっています。
postgres=arwdDxt/postgres
user01=arwdDxt/postgres
しかし、実行すると同じ結果に・・・
何をどう調べたら良いか、ヒントを教えてください。
よろしくお願いします。
0436NAME IS NULL
2015/01/21(水) 16:23:44.84ID:???pgbash かpsql にテキストファイルとは思うけど
psqlーU ユーザ名とかで同じことするとどうなる？
GRANTでよくやるのは、table だけ設定してシーケンス設定忘れとか
とりあえずエラーの詳細出すようにするか、手入力で同じことやってみて表示されるもの見るとか
0437NAME IS NULL
2015/01/21(水) 16:29:36.37ID:???0438435
2015/01/21(水) 17:32:31.47ID:7jfTDvH8FETCHTBL.sh の中はコンパイル後のアプリを実行しているだけです。
中身はCONECTして、CURSOR後、FETCHで全件読む感じだと思います。
COBOLでEXEC SQLを使っているので、いまいちよくわかってないです。
ってCONNECT時のユーザー名がpostgresになってる
もしかしてこれが原因かも？
あと、psql -u で同じ事やりましたが、同じエラーでした。
$ sudo -u user01 ./FETCHTBL.sh
SQLSTATE: 08001
Connection falied
0439435
2015/01/21(水) 17:37:19.18ID:7jfTDvH8CONNECT時のユーザーＩＤをuser01にしたら動きました！
ヒントいただけて本当に良かったです。
ありがとうございました♪
0440NAME IS NULL
2015/01/22(木) 00:12:45.91ID:???ついでに環境変数の PGUSER のことも知っておくと役に立つこともあるかもね
0441NAME IS NULL
2015/01/28(水) 23:01:34.11ID:???\o ファイル するしかないの？
標準出力に出なくなるから不便なんだけど。
0442NAME IS NULL
2015/01/29(木) 00:17:15.28ID:???0443NAME IS NULL
2015/01/29(木) 11:56:16.57ID:???teeだとファイル実行でしょ？
オラクルのspoolみたいのはないのかな。
0444NAME IS NULL
2015/01/29(木) 13:47:13.08ID:???ってことじゃねーの？ Oracle spool は知らんけど
0445NAME IS NULL
2015/01/29(木) 15:55:53.37ID:???？？？
>>444
そう。
0446NAME IS NULL
2015/01/29(木) 19:13:47.40ID:???できました。ありがとうございます。
0447NAME IS NULL
2015/01/30(金) 22:36:01.30ID:???0448NAME IS NULL
2015/01/30(金) 23:16:34.45ID:???https://wiki.postgresql.org/wiki/Running_%26_Installing_PostgreSQL_On_Native_Windows#What_versions_of_Windows_does_PostgreSQL_run_on.3F
0449NAME IS NULL
2015/01/31(土) 14:22:39.98ID:???0450NAME IS NULL
2015/02/07(土) 04:32:14.62ID:UIiC5NMDあくまで個人の趣味レベルのDBってことで
0451NAME IS NULL
2015/02/07(土) 04:48:31.80ID:???0452NAME IS NULL
2015/02/07(土) 06:59:26.80ID:???to_date() や to_timestamp() と例外処理を組み合わせれば簡単に作れるのでは？
君自身はその仕事をするレベルに達しているのかな？
0453NAME IS NULL
2015/02/07(土) 07:03:10.96ID:???0454NAME IS NULL
2015/02/07(土) 10:29:08.39ID:???SQL-Server で CSV から直接読む時に使ったことある
ないよりあった方がいいと思うけど、まあ必須じゃないわな
0455NAME IS NULL
2015/02/07(土) 13:35:53.62ID:???0456NAME IS NULL
2015/02/07(土) 15:27:11.35ID:???一般的に、例外をロジックとして使った関数は遅い（例外用の別の処理が入るから）
そんなことするぐらいならこうする ていうかこうした
case date_part('month',to_char(起点,'YYYY/MM/1')::date+設定日-1)
when date_part('month',起点) then (to_char(起点,'YYYY/MM/')||設定日)::date
else to_char(起点+'1 month','YYYY/MM/1')::date-1 end
isdateがあれば2つのdate_part('month'がいらない
仕事って、できりゃいいってことじゃないでしょ？手間かかったらアウト
不正判断が目的なら俺もそれ以外は思いつかん 今回はなくてよかった
まあ、大量不正判断が必要な現場でpostgre押し付ける暇人もいないだろうけど
>>453
不正判断はよそでやってってDBエンジンとして敗北じゃんｗ
データ処理速度こそが売りなのに
今回は月末切替が目的で、不正判断じゃないけど
0457NAME IS NULL
2015/02/07(土) 17:31:47.58ID:???least(
date_trunc('month', 起点 + '1 month'::interval)::date,
(date_trunc('month', 起点) + '1 day'::interval * (設定日 - 1))::date
)
ってことじゃないの？ isdate() は必須ではない気がするけどな。
なんにせよ、周りを見下してばかりで、いっしょに仕事をしたいタイプではないね。
0458NAME IS NULL
2015/02/07(土) 17:59:50.47ID:???DBはあくまでデータをため込んで効率よく取り出すためのものだ。不正判断とかそういうのはアプリでやるべき。
0459NAME IS NULL
2015/02/07(土) 18:19:00.43ID:???ただ、それをアプリでやるのは当たり前だが、不正な場合の代替処理をDB側でやりたいという需要もわからなくはない。
「データ処理速度こそが売り」というのは、明らかに間違った理解だ。
速いに越したことはないが、速さのみが必要なら他にもっと良いデータ保持方法はいくらでもある。
0460NAME IS NULL
2015/02/07(土) 19:24:58.23ID:???なんだそのめんどくさいコード片
0461NAME IS NULL
2015/02/07(土) 19:32:48.62ID:???末日締めなら末日締め用の値を設定日に入れるようにしたほうがいいと思うよ。
設定日が30だった場合に、31まである月も30で締めるんならそれでもいいけど。
0462NAME IS NULL
2015/02/07(土) 19:40:36.30ID:???case when 設定日 = 0 then
-- 末日(翌月一日の一日前)
date_trunc('month', 起点 + '1 month')::date - 1
else
-- 当月の設定日
date_trunc('month', 起点)::date + 設定日 - 1
end
0463NAME IS NULL
2015/02/07(土) 19:52:55.77ID:???0464NAME IS NULL
2015/02/07(土) 20:50:13.90ID:???勝手にデータやビジネスロジックの変更するなよ
毎月30日締めだけど、2/30は無いから3/1にしたいって話だろ？
0465NAME IS NULL
2015/02/07(土) 21:20:17.80ID:???to_char(起点+'1 month','YYYY/MM/1')::date-1
2月30日はこれじゃないの？
0466NAME IS NULL
2015/02/07(土) 21:25:15.37ID:???lastdayも作っておけばすっきりしたかもしんない。
例外だパフォーマンスだという前に、誤解をされることのない明快なコードを書いていきたいものです。
0467NAME IS NULL
2015/02/07(土) 21:25:37.59ID:???設定日のデータを勝手に変更せずに行う方法を考えろよ
0468NAME IS NULL
2015/02/07(土) 21:28:05.89ID:???それなら>>457のをちょっと変えればいいじゃん
0469NAME IS NULL
2015/02/07(土) 22:24:20.01ID:1PYerQOX0470NAME IS NULL
2015/02/07(土) 22:34:11.20ID:???0471NAME IS NULL
2015/02/07(土) 22:38:45.65ID:???0472NAME IS NULL
2015/02/08(日) 12:11:38.41ID:???おはようございますｗ
>>457
なるほど、SQL Serverにleastなんかないから思いつかなかった
月末と超過日で速い方取ったら月末ですね
要件的にはこうですが（2/30→2/28 要は存在しないなら月末）
least(
date_trunc('month', 起点 + '1 month')::date - 1,
(date_trunc('month', 起点)::date + 設定日 - 1
)
date_truncもすごいですなぁｗ 月単位で切り捨てると１日ですか
（従来感覚からすると魔法チックなので今はあのままにしときます）
まぁ環境押しつけらてる時点で、見下されてるのは誰なのかお察しください
0473NAME IS NULL
2015/02/08(日) 12:46:10.07ID:???だいたい手続型言語の既存バッチを直インポート→SQLに書き換えると数十倍～数百倍速くなるよ
なので事務員さんが溜め込んだ膨大な手書きExcelの分析となると、Excelから直インポートできるSQL Serverが最強
そんな仕事やりたいわけじゃないけど
0474NAME IS NULL
2015/02/08(日) 16:15:00.54ID:???って話じゃなかったね。おつかれさま。
0475NAME IS NULL
2015/02/08(日) 17:36:36.62ID:???なんてことをされたら、俺だったらクビにするわ。
0476NAME IS NULL
2015/02/08(日) 17:44:37.02ID:???また話を理解できない人が一人
0477NAME IS NULL
2015/02/08(日) 17:47:00.48ID:???0478NAME IS NULL
2015/02/08(日) 23:49:51.61ID:???0479NAME IS NULL
2015/02/09(月) 01:13:19.57ID:???個人の趣味レベルのDBエンジニアならともかく、プロならメジャーどころのDBMSの基本機能(日付処理)ぐらい華麗に使いこなせるべき。
0480NAME IS NULL
2015/02/09(月) 01:17:07.51ID:???そうだけどどうしたの
0481NAME IS NULL
2015/02/09(月) 18:12:40.70ID:???大きい会社はメーカー保証がない時点で導入不可だったりするし
0482NAME IS NULL
2015/02/09(月) 18:34:19.66ID:???0483NAME IS NULL
2015/02/09(月) 19:03:14.71ID:???わざわざ乗り換えた、さらに大きい会社もあるけどな
0484NAME IS NULL
2015/02/09(月) 20:27:04.05ID:???0485NAME IS NULL
2015/02/09(月) 20:29:23.46ID:???静的解析ツールの Coverity は、PostgreSQL 込みで納入されますがなにか？
採用したベンダーがサポートすりゃいいだけでしょ
0486NAME IS NULL
2015/02/09(月) 22:38:48.99ID:???0487NAME IS NULL
2015/02/10(火) 08:14:56.23ID:???一応仮にも技術的な話しかしてない人にそこまでしつこく人格攻撃するならもう一つ
例外利用にしろleastにしろ、やむを得ない場合の最終手段
leastは不要な側も計算してからの比較だから
この程度の場合は微妙だけどまずは判定してから必要な方だけ計算しようと考えるのが基本
全般的にその発想を守ってればパフォーマンスが落ちにくいという経験則がある
0488NAME IS NULL
2015/02/10(火) 08:56:53.84ID:???不要な処理はしないのは一般的には正しいけど、やはり基本は実測だと思うがなぁ。
PostgresのSQL処理は素朴なインタプリタだから、コンパイル型の言語とは特性も違うだろうし。
特に今回のケースでは least(A, B) でも case A when B else C end でも、
どっちも2回の計算をするのに差は無い (A+B vs. A+B or A+C)
大きな差が無くて、かつ >>450 (とその周囲) がSQL Serverに慣れているのならば
「SQL Serverっぽく」書くのが、総合的には正解だと思うんだ。
0489NAME IS NULL
2015/02/10(火) 10:34:53.51ID:???0490NAME IS NULL
2015/02/10(火) 13:51:56.57ID:???0491NAME IS NULL
2015/02/10(火) 15:30:47.92ID:???これってバグ？
0492NAME IS NULL
2015/02/10(火) 16:13:44.49ID:???とりあえず 9.2.10 にアップデートしてからまたおいで。
0493NAME IS NULL
2015/02/10(火) 16:17:59.86ID:???0494NAME IS NULL
2015/02/10(火) 16:55:45.90ID:???でもまあ、いつでもお試しインストールできるようにしといたほうが、、
0495NAME IS NULL
2015/02/10(火) 22:35:12.82ID:???いきなりは無理かな。
何日もかけて検証しないといけないかな。
0496NAME IS NULL
2015/02/11(水) 01:20:28.68ID:???設定やSQLで互換性を気にする部分をまとめてくれてるところは無いですか？
0497NAME IS NULL
2015/02/11(水) 03:58:24.60ID:???リリースノート超詳しいよ
0498NAME IS NULL
2015/02/11(水) 04:49:31.22ID:???何をもって検証完了とするのか
0499NAME IS NULL
2015/02/11(水) 08:02:50.46ID:???0500NAME IS NULL
2015/02/11(水) 09:50:04.84ID:???0501NAME IS NULL
2015/02/11(水) 11:05:27.58ID:???クエリが糞遅くなるとかしょっちゅうだったが、最近はもう安定したのかな。
0502NAME IS NULL
2015/02/11(水) 14:16:54.63ID:???あるだろし、移行は怖いやね。
でも いつかやらんといかんだろしー どーすっかなー
移行計画書書くかなーと数年悩んだりしてw
0503NAME IS NULL
2015/02/11(水) 14:43:51.00ID:???9.2.10 へのアップデートを薦めたんじゃないのか
0504NAME IS NULL
2015/02/11(水) 15:03:08.34ID:???0505NAME IS NULL
2015/02/11(水) 19:49:22.47ID:???逆に糞速くなることもよくあったねぇ
0506NAME IS NULL
2015/02/12(木) 11:48:31.74ID:???9.4より古いわけじゃない。
0507NAME IS NULL
2015/02/12(木) 18:18:01.50ID:???> CVE-2015-0241 "to_char"関数のバッファオーバラン
ぎゃー知らんがな
12月から開発してるから9.3ですよ 今更対応しませんよ 選定したのこっちじゃないしｗ
一応プログラム側でSQL全体で10MB制限してますが根拠なし（100MBじゃ大き過ぎるだろうという感覚的なものｗ 10MB自体絶対行くわけないし）
取ろうとしてるISOに引っかかるのかどうか知りませんが
逆に、何のDBでどんなルールならISO通るのかISOに聞いてから始めれば？って思いますが
0508NAME IS NULL
2015/02/12(木) 18:25:51.73ID:???0509NAME IS NULL
2015/02/13(金) 00:47:13.68ID:???9.3も修正の対象になってるやん。
マイナーバージョンアップすらできないならどの道違うところで問題が起きてたよ。
0510NAME IS NULL
2015/02/22(日) 14:25:58.35ID:Xk5uRKDC[tbl]
id | val
-----------
1 | 1
という状態で、Aさんが
UPDATE tbl SET val = 2 WHERE id = 1 AND val = 1;
Bさんが
UPDATE tbl SET val = 3 WHERE id = 1 AND val = 1;
としてほぼ同時にアクセスしたときに片方は確実に更新レコード数0になりますか？
0511NAME IS NULL
2015/02/22(日) 14:46:28.09ID:???0513NAME IS NULL
2015/03/09(月) 08:49:54.06ID:???postgresql-9.4.1-1-windows.exe
There has been an error.
Unknown error while running C\Documents and Setting\xxxxxx\LocalSettings\Temp\postgres_instller_xxxx\getlocales.exe
0514NAME IS NULL
2015/03/09(月) 17:15:54.91ID:???create table tbl
(
col1 varchar(16) not null,
col2 varchar(8) not null,
col3 varchar(16) not null,
col4 varchar(8) not null,
col5 smallint not null,
col6 smallint not null,
col7 smallint not null,
col8 date not null,
col9 int[48],
unique (col1, col2, col3, col4, col5, col6, col7, col8)
) without oids tablespace ts_data;
のテーブルに約4億件のデータがあり、これに、1000件、5000件、10000件のデータをinsertすると、2.2秒、14.2秒、31.5秒かかります。
このテーブルに、次のインデックスを追加し、同じことを行うと、10.0秒、47.5秒、94.2秒かかりました。
create index idx on tbl using btree
( col8, col5, col6, col7 ) tablespace ts_index;
ここで、ts_dataとts_indexは同じ物理ディスクに配置し、一意制約インデックスは、別ディスクに配置しています。
ひとつめの質問ですが、インデックスをひとつ追加したたけで、insert性能が1/5から1/3程度に低下することはありますか？
また、同じテーブルのupdate性能も、インデックスあり1.4ms/レコードから、インデックスあり9.4ms/レコードに低下しています。このとき、updateのwhere句にcol1からcol7までの条件指定を行い、一意制約インデックスが使われて更新処理が行われているのを確認しています。
同じテーブルのselect性能は、データ292万件選択した場合、インデックスなし271.4秒、インデックスあり171秒と、4割近く改善しています。効果が劇的でないのは、データのソート処理を行っており、ディスクアクセスが発生しているためです。
ふたつめの質問は、selectで性能改善しているのに、updateで処理性能の悪化がみられたのですが、こんなことはあるのでしょうか。
テストは、C言語で書いたテストプログラムを使い、insert->select->updateと処理し、このプログラムを10回繰り返して測定しました。
みっつめの質問は、insert/updateの性能を改善するには、どこに着目すればよいでしょうか？
足りない情報があれば指摘ください。
0515NAME IS NULL
2015/03/09(月) 17:37:32.14ID:???どっかに金払ってサポート頼めよ。
とりあえずuniqueインデックスの張り方は頭おかしい。 無料では付き合いたくない。
0516NAME IS NULL
2015/03/09(月) 17:50:22.25ID:???0517NAME IS NULL
2015/03/09(月) 18:00:11.86ID:???まずは、その性能が妥当かどうか、なにかがボトルネックになっていないかを、統計情報等から判断してみては？
> みっつめの質問は、insert/updateの性能を改善するには、どこに着目すればよいでしょうか？
パーティショニングとか。
0518NAME IS NULL
2015/03/09(月) 18:02:58.65ID:???> 解決するだけでうん万円いけそうね
1日5万でしょ。
1週間(5日)かかったら25万。
2週間なら50万。
0519NAME IS NULL
2015/03/09(月) 18:15:46.94ID:???Amazon RDSとか。使ったことないけど。
0520NAME IS NULL
2015/03/09(月) 18:58:20.34ID:???僕はＤＢ技術者になろうとおもいます！
ｵﾎﾝ
４億件がベタに展開されてるのって怖くないのかな・・・
0521NAME IS NULL
2015/03/09(月) 20:24:45.03ID:???> ふたつめの質問は、selectで性能改善しているのに、updateで処理性能の悪化がみられたのですが、こんなことはあるのでしょうか。
（一般論として）当たり前だろ
どんな場合でも速くなるなら、インデックス張りまくるわ
0522NAME IS NULL
2015/03/09(月) 20:41:21.08ID:???つか、SELECTで性能改善するために、UPDATE時に何が起こってるのか分かってる？
0523NAME IS NULL
2015/03/09(月) 20:54:25.10ID:???何で俺にアンカーしてるんだ？
0524NAME IS NULL
2015/03/09(月) 20:58:58.96ID:???アンカー間違えたよ、ごめん
まぁ、何が起こってるか分かってるなら、あんなuniqueインデックスの張り方しないか
0525NAME IS NULL
2015/03/09(月) 21:12:59.74ID:???> アンカー間違えたよ、ごめん
いいってことよ
> まぁ、何が起こってるか分かってるなら、あんなuniqueインデックスの張り方しないか
つか、あんな状態で億単位のレコード突っ込んでもそれなりに動くことに驚いたわ
0526NAME IS NULL
2015/03/09(月) 21:43:10.26ID:???プライマリキーはcol1～col8でいいの？
それなら、uniqueインデックスを col 8 5 6 7 1 2 3 4にして、ts_indexを作らないという選択肢はどうだろう
0527NAME IS NULL
2015/03/09(月) 21:52:08.67ID:???一意制約狂っとるといわれても、論理的にも、実際の業務プログラムでも、この
部分が一意なので。
しかも、業務プログラム側が、やってくるデータが新規追加なのか、更新なのか
分からないって。毎回全データに1件ずつselectかけて、選択されたらupdate、できなかったらinsertの処理
を行っていくということをしなければなりません。
これを単純にするために、全件insert処理を行い2重登録は一意制約ではじい
てupdate処理をしようと計画しています。
なんでこんなことになっているかというと、現状動いているシステムがあり、こ
れを元に新しい要件に対応させようとすると、フラットファイル(を管理している
ミドルウェアを介するのだが)で管理しているデータが、ファイル容量制限で分割
しなければならなくなり、それならRDBで管理させようとなったためです。
0528NAME IS NULL
2015/03/09(月) 21:58:34.09ID:???統計情報のどこを見ればいいのか、まだよく分かっていません。この、1月からPostgreSQL初めたので。
しかも、仕事場は、インターネット接続できず、調べ物はPostgreSQLのオンライ
ンマニュアルだけで調べてます。どうしても分からなければ、自前のスマートフォンで検索。
今も、スマートフォンから2chです。
0529NAME IS NULL
2015/03/09(月) 22:01:36.73ID:???追加。
パーティショニングは、検討していますが、論理設計やって、その設計で問題ないかを検証してて、問題ありという状態です。
0530NAME IS NULL
2015/03/09(月) 22:25:08.37ID:???今は、設計限界までデータ投入したときにどこまで遅くなるかを測っており、これを元に
実際のアプリケーションでの性能見積の基礎データにするのです。
運用されるときは、このサイズの1/10くらいまで大きくなることを見込んでいます。
このサイズのテーブルが3テーブルできて、テーブルの設計容量がすべて合わせて
250GB、インデックスを入れると、400GB程度を見込んでいます。
これに、実際の運用時には同期と非同期の1台ずつのレプリケーションサーバがぶら
下がる予定です。非同期サーバは、遠隔地に設置。
0531NAME IS NULL
2015/03/09(月) 22:27:34.18ID:???インデックスに設定している項目は、更新かけない(基本的に、insertのみ更新)ので、
インデックスの追加によるupdateへの影響はないかなと、理解していました。
0532NAME IS NULL
2015/03/09(月) 22:31:20.43ID:???正直、よく分かっていません。
何を見れば、ここらのことを理解できるようになりますか？
今の理解は、インデックスを構成しているカラムを更新しないと、インデックスの更新は
発生しない(ような仕組みが取り入れられている)ということです。
この理解、間違っていますか？
0533NAME IS NULL
2015/03/09(月) 22:40:21.58ID:???えっと、こいつの元々のテーブル設計は、col9の配列を要素ごとに1レコードに分解した
ものでした。正規化を突き詰め、論理的に存在しないデータは、DB上物理的に存在しな
い(48個の要素のうち、データが有効なのは数件)という設計をしたのです。
当然、設計データ量をすべて満たすとレコード数は48倍になり、キー(80バイトのレコー
ドのうち、キーが76バイトある)によりテーブル容量も約48倍、インデックス容量も48倍
となり、select(sortあり、一時データが5GB以上になってた)が2時間から5時間となって
しまい、オンライン(なんです)処理にならなかったので、設計を変更して今に至ります。
0534NAME IS NULL
2015/03/09(月) 22:52:55.88ID:???col1～col8ですが、今回のテストプログラムでは、外しているのですが、col1とcol3も
検索条件に入ってくる(業務的にはcol1/col3の5バイト目で比較というのもある。さすが
にこれは毎回やっとれんので、col1/col3を管理してるマスタにカラムを追加して持た
せようと思う)ので、インデックス1本というわけにはいきそうにありません。
ちなみに、col1/col3は、同じマスタを参照し、設計件数2000件、col8は、データを2年
持たせる仕様で732種類(366日x2年)、col5,col6,col7は、それぞれ2つの値を持ち、必
ず指定されます。
いや、もしかしたら、unique (col8,col5,col6,col7,col1,col3,col4,col5)で張れるかもしれ
ない。
0535NAME IS NULL
2015/03/09(月) 23:08:09.31ID:???データベースを作成するときの文字コード、EUC_JPがいいのか、UTF8がいいのか悩んで
います。
クライアントは基本的にC言語で書かれたUNIX(Linux)アプリケーションで、そこの環境は
EUCなのですが、データベースの寿命が10年から20年くらい使われることが見込まれて
います。
この会社で過去2年に導入したPostgreSQLは、EUC_JPで作成されており、それに従うの
が正しいのか、UTF8が正しいのか。わたしは、将来的にどのプラットフォームでも使える、
UTF8がいいのではないかと思っているのですが。ここらの規約は定められていません。
DBがUTF8で、クライアントEUC_JPだと、コード変換に時間がかかるから、EUC_JPがい
いとか、いやいや、やっぱり時代はUTF8でしょとか、どうなんでしょう？
0536NAME IS NULL
2015/03/09(月) 23:16:10.93ID:???> すみません、もうひとつ教えてください。
> データベースを作成するときの文字コード、EUC_JPがいいのか、UTF8がいいのか悩んで
> います。
> クライアントは基本的にC言語で書かれたUNIX(Linux)アプリケーションで、そこの環境は
> EUCなのですが、データベースの寿命が10年から20年くらい使われることが見込まれて
> います。
いやいや、よく考えてみると、UNIXプログラムで日本語表示する部分てないぞ。UIは、
Excelで、UNIXからCSV経由でデータの受け渡しが行われるので、UTF8でいいのでは？
どっちみち、SJISでファイル書かにゃならんのやから、コード変換DBにやらせて、アプリ
ケーションでやってる、EUC->SJISの処理が減らせるか・・・
0537NAME IS NULL
2015/03/10(火) 00:39:51.77ID:???もしくは、極めて無駄の多いテーブル設計になっているように読める。
イチから考え直してみたらどうでしょ。
0538NAME IS NULL
2015/03/10(火) 07:27:18.95ID:???おはようございます。
どうでもいいテストレコードといわれると、そうなんですが、いただいてる仕様から起こすと
こうなのかなと。
無駄の多いレコードというご指摘、配列のところは無駄なんですが、これをやめるとレコー
ド数が爆発してしまう可能性があって。どのくらい、実際にデータが入るかは、ケースバイ
ケースで、1個の時もあれば、5個の時もある。48個用意しているのは、1日のうちに、30分
毎のデータを管理しなければならないためです。つまり、配列の要素番号は、時刻に対応
してるんです。
0539NAME IS NULL
2015/03/10(火) 07:32:16.66ID:???「無料では付き合いたくない」のは「この案件」ではなく、「この質問者」を意図していた。
予想通りの流れで笑ったわ。
0540NAME IS NULL
2015/03/10(火) 11:30:14.63ID:???性能は、データサイズによって線形になるとは限らないよ。
実運用時のデータサイズ見積もりが4億レコードじゃなくて4000万レコードなら、それをベースに検証したほうがいい。
4億レコードの場合の性能改善策と4000万レコードのそれでは、全然別物の可能性が大きい。
0541NAME IS NULL
2015/03/10(火) 12:01:45.92ID:???御意。
0542NAME IS NULL
2015/03/10(火) 16:05:44.90ID:???48個のうち有効なデータが0個の日はあるの？
0543NAME IS NULL
2015/03/10(火) 17:55:29.79ID:???それなんか設計に関係あんの？
0544NAME IS NULL
2015/03/10(火) 18:13:44.92ID:???あるから聞いてるんだけど
0545NAME IS NULL
2015/03/10(火) 18:27:20.11ID:???0546NAME IS NULL
2015/03/10(火) 20:13:33.10ID:???そのときは、データが飛んでこないので、DBには記録されない。
0547NAME IS NULL
2015/03/10(火) 20:20:10.53ID:???運用段階で飛んでこない日がどれくらいあるのかは推測できるのかな。
今フルに埋まる前提でテストレコード作ってるからそうなっているんだろうけれど
それが運用段階と乖離している可能性がないか見直してみたらどうだろう。
たとえば、普通の受発注システムにおいて、DB設計上キーが42億までいけるからといって
42億埋まった状態のテストはしないよね。
0548NAME IS NULL
2015/03/10(火) 20:20:50.34ID:???配列で持たせないほうが効率的になりうるので。
0549NAME IS NULL
2015/03/10(火) 20:24:11.75ID:???今朝、仕事場に行ったら、PostgreSQLが立ち上がらず、DBクラスタ毎物理削除させられて、検証
環境再作成となった。
データ件数、パーティショニング含めて、次の検証どうするか考え中。
それでも、運用環境とは違うので、どう評価すべきかまだ分かっていない。
そもそも、/パーティションにDBクラスタ置いてるのがおかしいだろうとは思うが、そこの設定は発
注元なので、今は厳しく言ってない。本番は別パーティションにしてほしいと思ってる。
0550NAME IS NULL
2015/03/10(火) 20:36:41.74ID:???実データは、どれだけ発生するのかは誰も把握してない。
RFPには、全国で40000件の取引/日ということが書いてあって、これに応札したときの
想定件数が8000件/日であると、教えられた(受注はある一部分の地域のみ)だけで、
今のシステムが2000取引/日の容量で動いてるという、この二つの情報だけで、設計
してるのが現状です。
ここらの条件については、発注元に改めてきいているというのが現状ですが、わたしの
仕事の元請の上に、その会社の親会社がいて、そこの方がお客様と話をされてて、お
金の話をされてるので、わたしにできるのは与えられた環境でベストを出すことだけな
のです。
0551NAME IS NULL
2015/03/10(火) 20:43:06.96ID:???0552NAME IS NULL
2015/03/10(火) 20:48:35.76ID:???机上の計算だけど、取引の平均で48点のうち、1/12までならキーの大きさを考えても
30分毎のデータをばらしたほうがデータ総容量が小さくなると試算したのですが、テス
トするときには、設計件数の上限でデータを出してほしいといわれたので。
実際に、どれだけ有効なデータが入ってるかは、運用しているシステムのデータを分
析すれば出るのですが、発注元はそこらのデータを把握してないんです。しかも、取
引件数そのものが、現状動いてるシステムの設計件数の4倍から11倍になってるの
で、このシステムの稼動時のデータ件数の見積が現状出てません。
0553NAME IS NULL
2015/03/10(火) 20:52:43.45ID:???で、その入札が取れた後に実装段階になって、人集め始めて、(わたしは、PostgreSQL
知りませんよと面接のときに言ったにもかかわらず仕事が来て)いまいろいろとわちゃわ
ちゃしています。
0554NAME IS NULL
2015/03/11(水) 04:21:47.96ID:???一件ずつinsertしないとダメなの？
ある程度データまとめて一括してinsert。その際returning句入れておいて挿入結果を取得できるようにする。
挿入結果取得して返ってこなかったものをupdate。
とかだったらSQL的に回数減るから少しマシになると思うけど。
0555NAME IS NULL
2015/03/11(水) 20:03:45.21ID:???insertだけならそれでもいいかもしれませんが、来たデータがinsertなのか、update
なのか分からない、しかも、col1/col2/col3/col4がマスタに登録されてなかったら、
マスタ登録を行わなければならないということをかんがみて、1件ずつcommitさせる
必要があるかなと思ってます。
0556NAME IS NULL
2015/03/11(水) 21:03:03.26ID:???そうだろうから>>554のレスがついたんじゃないかな。
0557NAME IS NULL
2015/03/11(水) 21:14:32.22ID:???DB云々の問題ではないような・・・
0558NAME IS NULL
2015/03/11(水) 22:30:34.69ID:???0559NAME IS NULL
2015/03/11(水) 22:46:47.22ID:???0560NAME IS NULL
2015/03/11(水) 23:15:37.19ID:???にしようと前任者が考えたんだろうけど（適当）、
担当者の問題じゃなくて、係か課の問題じゃないのか。
他のDBMSでも同種の問題発声の匂いがする。 適当ですまん。
0561NAME IS NULL
2015/03/12(木) 10:26:36.87ID:???もしもそっちの方でも期待した性能が出なかったら仕様が悪いということで、そもそもの設計を変えるしか無い。
期待した性能出たら、その時はpostgre固有の問題なんだからpostgreスレにくればいい。まあ乗り換えた方が早いけど。
0562NAME IS NULL
2015/03/12(木) 11:16:06.64ID:???製品名もまともに覚えられないクソ業者
0563NAME IS NULL
2015/03/12(木) 11:51:26.37ID:???postgreと書く奴はほぼ初心者だから
0564NAME IS NULL
2015/03/12(木) 12:55:16.35ID:???発想も初心者丸出し
0565NAME IS NULL
2015/03/12(木) 14:45:11.05ID:???0566NAME IS NULL
2015/03/12(木) 15:04:15.55ID:???なんで、データ件数の見積もりができないのかわからん。
> しかも、取引件数そのものが、現状動いてるシステムの設計件数の4倍から11倍になってるの
> で、このシステムの稼動時のデータ件数の見積が現状出てません。
今動いてるのが2000取引/日だとわかってるんだから、その設計時の見積もりがどうであったかなんて
関係ないよね。
そして、FRPに8000件/日と明記されてるんだから、データ保存期間を考えれば見積もりできるだろ。
> 設計件数の上限でデータを出してほしい
というんだから、8000トランザクション*48個のデータ*保存日数で見積もればいいんじゃないの？
で、物理設計を絡めて性能評価するんであれば、レコード数が多いなら、パーティショニングを考慮して性能評価すれば良いし。
最初4億レコードとか言ってたのは、一体何だったの？
8000records/dayなら50,000日(188年)分なんだけど。
0567NAME IS NULL
2015/03/12(木) 15:07:34.29ID:???JSONBの力は大きいのかね。
0568NAME IS NULL
2015/03/12(木) 15:19:36.41ID:???なら、4億レコードというのは27年分か。
1日MAXで、40,000*48=192,000個のデータの登録が必要。
4億レコードはデータを配列で持つ場合だから、27年分というのが正しいなら、データをばらすと192億レコードか。
0569NAME IS NULL
2015/03/12(木) 15:49:59.78ID:???もうやめにしませんか 新垣 隆
0570NAME IS NULL
2015/03/12(木) 16:15:14.10ID:???>>514
> のテーブルに約4億件のデータがあり、これに、1000件、5000件、10000件のデータをinsertすると、2.2秒、14.2秒、31.5秒かかります。
> このテーブルに、次のインデックスを追加し、同じことを行うと、10.0秒、47.5秒、94.2秒かかりました。
インデックス付きでも1日分のデータを登録するのに400秒くらいしかかからないじゃん。
余裕でしょ。
終わり。
0571NAME IS NULL
2015/03/12(木) 19:57:36.57ID:???> col8は、データを2年持たせる仕様で732種類(366日x2年)
見落としてんぞ。
0572NAME IS NULL
2015/03/12(木) 20:21:07.58ID:???> 1日MAXで、40,000*48=192,000個のデータの登録
これもおかしい。>>538によると、
> 48個用意しているのは、1日のうちに、30分毎のデータを管理しなければならないためです。
> つまり、配列の要素番号は、時刻に対応してる
つまり、1件1レコードであるという前提で計算を進めてるのにあわせるなら平均保持件数は
40000(/日)*366(日)*2(年)レコードでざっくり3000万件。
あとFRPなんて間違いはさすがに恥ずかしいよ
0573NAME IS NULL
2015/03/12(木) 21:17:22.31ID:???0574NAME IS NULL
2015/03/12(木) 21:38:45.70ID:???0575NAME IS NULL
2015/03/13(金) 10:12:16.15ID:???> 見落としてんぞ。
見落としてた。
2年って決まってるなら、なおさら見積もりできない理由がない。
>>572
> つまり、1件1レコードであるという前提で計算を進めてるのにあわせるなら平均保持件数は
> 40000(/日)*366(日)*2(年)レコードでざっくり3000万件。
1日1レコードという前提じゃなくて、データのMAX個数の話だよ。
48個を1レコードで保持するなら3,000万件、ばらすなら、MAX144,000万件。
> あとFRPなんて間違いはさすがに恥ずかしいよ
意味は知ってたけど、自分でタイプすることなんてないから間違えた。
まあそれはともかくとして、
・1日40,000件
・1件あたり最大データ個数は48件
・データ保存期間は2年
というのがわかっていて、なんの見積もりができないのかがわからない。
0576NAME IS NULL
2015/03/13(金) 10:54:14.47ID:???3千万件ならsmallサイズじゃないか（いいすぎ）
0577NAME IS NULL
2015/03/13(金) 15:02:04.02ID:???0578NAME IS NULL
2015/03/13(金) 15:48:49.35ID:???> col9 int[48],
で4億レコードって話だった
で、常に48個のデータが入ってるわけじゃないから、
> col9 int,
とばらした方がいいのかどうかみたいな話
0579NAME IS NULL
2015/03/14(土) 01:24:06.73ID:???0580NAME IS NULL
2015/03/21(土) 01:30:26.56ID:Re73Z7u2なんですけど、これってなんか問題ありますか？
年商50億の基幹システムの基幹DBです。
よろしくお願いします m(_*_)m
0581NAME IS NULL
2015/03/21(土) 02:06:05.64ID:???無問題
0582NAME IS NULL
2015/03/21(土) 03:01:46.32ID:???0583NAME IS NULL
2015/03/21(土) 06:18:18.37ID:???> 年商50億の基幹システムの基幹DBです。
ネタだとは思うが、サポート受けてそこへ聞けよ
https://www.pgecons.org/postgresql-info/services/
0584NAME IS NULL
2015/03/21(土) 20:44:43.87ID:???よろしくお願いします m(_*_)m
0585NAME IS NULL
2015/03/23(月) 10:26:31.67ID:???0586NAME IS NULL
2015/03/23(月) 13:17:24.48ID:???0587NAME IS NULL
2015/03/23(月) 19:36:19.74ID:76CzxVm8釣りかもしれんが一応回答しておく。
8.4はコミュニケーションベースではもうアップデートされないんじゃないか？
今後の維持管理を考えるなら、9.4かせめて9.3にしないと危ない気がする。
有料サポートの会社なら金次第では8.4でも対応してくれるかもしれないが。
0588NAME IS NULL
2015/03/23(月) 21:56:37.06ID:???0589NAME IS NULL
2015/03/23(月) 22:31:54.04ID:???リカバリにバグのあるバージョンだったと気付くわけだ
0590NAME IS NULL
2015/03/25(水) 18:58:45.39ID:???たぶん、confの設定だとは思うんですが、どの本買えばその辺りのことを含めて書いてありますか？
初心者にやさしい本を紹介してください。
postgresql 8.4を使用するつもりです
0591NAME IS NULL
2015/03/25(水) 19:42:30.45ID:???マイナバージョンは最新版にすればいいのはわけるけどぉ
0592590
2015/03/26(木) 18:51:21.29ID:???0593NAME IS NULL
2015/03/26(木) 21:08:19.01ID:???0594590
2015/03/27(金) 07:47:23.03ID:???webだと実行userがapacheになるから、ident認証はダメだし
いや、apacheにDBアクセス権を与えてやればいいのかな？
0595NAME IS NULL
2015/03/27(金) 08:59:12.73ID:qteX3izRまあ、用心するに越したことはないけど、
自作の拡張機能を組み込んでいるのでなければ
PostgreSQLのメジャーバージョン間の互換性は割と高いほうだと思うので
あまりバージョンアップを怖がるのもどうかとは思う。
0596NAME IS NULL
2015/04/02(木) 18:42:01.46ID:???まあ一番上が変わるときはそんなもんだが
0597NAME IS NULL
2015/04/02(木) 20:06:34.89ID:???などと言ってないでないで誰が責任を取るかって事だね。
マイナバジョンはDEBUGの結果だし、無視していいって事はまずない。
結局テストフェーズの部門的な確立なのかも・・・
0598NAME IS NULL
2015/04/02(木) 20:29:26.73ID:???互換性確認ツールってないんだろうか？
SQL入れたら結果が出るとか
0599NAME IS NULL
2015/04/02(木) 22:50:39.28ID:???試したいSQL出せてるなら9で流せばいいだけじゃない？
何か読み間違えてたらごめん。
0600NAME IS NULL
2015/04/03(金) 09:05:22.97ID:???学会員と思しき人物からのいやがらせ
面談強要(1477件)無言電話(1087件)
中傷ビラ(863件)手紙の開封など(694件)脅迫(電話を含む)(656件)
監視(475件)尾行(429件)
器物損壊(208件)盗聴(80件)汚物投棄(79件)暴行(49件)
0601NAME IS NULL
2015/04/13(月) 11:26:43.38ID:SLfZlGqV固定長ファイルの取り込みが必要になっていて、エンコード変換が必要な場合にどう動くのか知りたい
元ファイル: sjis
カラム1: 20byte (漢字含)
DB: utf8
table tbl_aaa
clm1 char(30)
オプションで -encoding=sjis 指定して、コントロールファイルに指定するカラムサイズは20？
0602NAME IS NULL
2015/04/13(月) 20:38:00.58ID:???入力データで数えるから20
ところでcharは文字数指定だから
utf8だとしても10か20なんじゃ？
0603NAME IS NULL
2015/04/14(火) 01:41:00.45ID:???0604NAME IS NULL
2015/04/14(火) 01:50:32.75ID:???0605NAME IS NULL
2015/04/14(火) 04:09:35.58ID:???copy (select ～ ) to
0606NAME IS NULL
2015/04/14(火) 07:20:21.20ID:KXEAwBs7ありがとうございます
手元に動かせる環境なくて直接ソース読んだだけなのでちょっと不安でした
charのサイズは30文字であってます
※ 別の入力では上限30の可変長…
0607NAME IS NULL
2015/04/15(水) 06:03:59.16ID:???copyの方が高速らしいと見た気がするので、、、
>>605
lpad指定ですかね。
numericやdecimal型で桁数を指定してテープル作ったのだから、固定長で出力させるOptionがあったら良いのに、、、
0608NAME IS NULL
2015/04/15(水) 07:14:37.55ID:???「固定長出力の数値型」をユーザ定義する機能はすでにある
自前で用意するのはtextoutだけだから簡単だろう
0609NAME IS NULL
2015/04/15(水) 21:19:54.45ID:???検索のやり方が悪いせいか、答えに行き着きませんでした。
もう少しヒントをお願いします。
0610NAME IS NULL
2015/04/21(火) 19:02:45.95ID:???0611NAME IS NULL
2015/04/22(水) 06:10:21.24ID:???ドキュメント（15.6節）ではこう書いてるから9.4も動くかもね
PostgreSQLは次のオペレーティングシステムで動作することを期待できます。 （略）Windows (Win2000 SP4以降)
配布バイナリで動作するかは知らん。
ググると8.3を動作確認済みとしてるサイトはあった。
0612NAME IS NULL
2015/05/02(土) 04:16:01.14ID:???0613NAME IS NULL
2015/05/02(土) 13:40:16.22ID:???秋にリーマン２で、５年内に世界中の都市部で大陥没現象で行政インフラ
完全停止、３ヶ月くらい。リアル北斗。空気感染型エボラの世界的大流行
バタバタ人が消えてゆく。でも頑張ろうぜ。
0614NAME IS NULL
2015/05/08(金) 04:20:38.48ID:???0615NAME IS NULL
2015/05/08(金) 04:38:44.95ID:???0616NAME IS NULL
2015/05/08(金) 09:07:05.12ID:???つかインストールとDB作成は別だろ
Winだとインストーラーがやってくれる気もしたが、それに頼らんほうが・・・
0617NAME IS NULL
2015/05/08(金) 20:31:29.11ID:???『Ploblem running post-install step. Installation may not
complete correctly
Error reading file O:/PostgreSQL/9.0/data/postgresql.conf』
プログラムはC:¥Program Files¥PostgreSQL¥9.0に指定
o:はデータ専用パーティション
C:¥Program Files¥PostgreSQL以下 、O:以下、C:¥WINNT以下にいずれもEVERYONEへのフルコントロール権限を付与
C:¥Documents and Settingsのpostgres以下、postgres¥<コンピュータ名>以下にいずれもアドミニストレータ、システム、postgresへのフルコントロール権限を付与
このインストール（失敗）後、postgresでログインしなおしてpostgresql-9.0サービスを起動しようとすると『エラー 5: アクセスが拒否されました。』
アドミニストレータでログインでサービス起動しようとすると、『エラー 1053: そのサービスは指定時間内に開始要求または制御要求に応答しませんでした。』
余談ですが、現在本家で配布してるバイナリインストーラは全てWindows 2000非対応のようです。起動すると黙って落ちます
0618NAME IS NULL
2015/05/08(金) 21:18:59.92ID:???Windowsのサービスとして登録される時の、起動オプションのPGDATAのパスが
フォルダの変更に対応していないバグがあった気がする。
サービス管理を開いて自分で修正すれば動くんじゃないかな。
まぁ、自分で解決するスキルも有料サポートを頼む金も無いなら
古いOSや古いバージョンは使うべきではないよ。
0619NAME IS NULL
2015/05/09(土) 12:35:14.41ID:???initdb -D O:/Postgr～うんぬんかんぬんで動きました。ありがとうごさいます
0620NAME IS NULL
2015/05/12(火) 11:49:31.40ID:lvu8idO3PostgreSQL の付属ドキュメントによると、
=====================================
慣習的には、キーワードを大文字で、名前を小文字で書きます。 例えば下記のようになります。
UPDATE my_table SET a = 5;
=====================================
と記されていますが、これを
update my_table set a = 5;
と書いても結果は変わらないですよね？
記法(書法？)だけのことなんでしょうか？
最初はドキュメントどおりにキーワードは大文字で書いていたのですが、面倒になりました。
全て小文字で書きたいです。
なにか問題はありますか？
0621NAME IS NULL
2015/05/12(火) 11:56:44.92ID:???俺は全部小文字だと見づらいから予約語は大文字にするけどね。
0622NAME IS NULL
2015/05/13(水) 00:30:21.66ID:???0623NAME IS NULL
2015/05/13(水) 03:04:38.52ID:???0624NAME IS NULL
2015/05/13(水) 08:46:03.86ID:???PostgreSQLは小文字だね
0625NAME IS NULL
2015/05/13(水) 18:17:50.69ID:???＞親テーブル上の検査制約と非NULL制約はその子テーブルに自動的に継承されます。 他の種類の制約（一意性制約、プライマリキー、外部キー制約）は継承されません。
CHECKの部分は引き継がれて、UNIQUEは引き継がれず設定し直しなんですか？
これは何故ですか？
0626NAME IS NULL
2015/05/13(水) 19:19:34.62ID:???継承テーブルに跨ったユニーク性を保証できないからかな。
そのテーブル内だけなら問題ないけど、何をユニークにしたいかは用途に依存するから。
なお、設定しなおす件については LIKE 親 INCLUDING xxx で自動化できたはず。
0627NAME IS NULL
2015/05/13(水) 20:52:59.61ID:???＞CHECK制約は、INCLUDING CONSTRAINTSが指定された場合にのみコピーされます。 他の種類の制約は決してコピーされません。
とありますが、一意性制約のコピーができるというのでしょうか？
0628NAME IS NULL
2015/05/13(水) 22:10:53.68ID:???先ずマニュアルを読め。一意性制約は暗黙のインデックスを張るからか、INCLUDING INDEXES の管轄のようだ。
https://www.postgresql.jp/document/9.4/html/sql-createtable.html
| 元のテーブル上のインデックス、PRIMARY KEY、およびUNIQUE制約は、INCLUDING INDEXESが指定された場合にのみ新しいテーブル上に作成されます。
0629NAME IS NULL
2015/05/13(水) 22:33:25.60ID:???8.4のマニュアル読んでました(^ω^;)ﾄﾞﾓ
0630NAME IS NULL
2015/05/17(日) 19:11:41.46ID:???あるテーブルを、運用性とデータ件数を考慮して、パーティションテーブル化して運用しようと思っているのですが、insert/select/deleteは問題ないのですが、updateだけパーティションテーブル化した方が20倍遅くなるように見えます。
実行時間は、PQexec()関数の前後で時刻を取得し、その差を実行時間としています。パーティション化しないと、0.6msecで終了するupdateが、パーティション化したテーブルで実行すると12msecかかっているように見えるのです。
しかし、サーバにauto_explainモジュールを導入し、1msec以上の実行時間か掛かっている処理について、ログを出力するように設定しても、パーティション化した方でもログは出力されません。
使っているPostgreSQLは、9.2.4で、パーティション化すると、133個の子テーブルが存在します。テストは、パーティション化してるかどうかの違いだけで、ハードウェアもテストデータも、テストプログラムも全く同じものを使っています。
何故、パーティション化の有無だけで、updateだけ性能悪化したように見えるのでしょうか？
0631NAME IS NULL
2015/05/17(日) 20:10:45.19ID:???パーティションキーに変更はあるの？
パーティション間の移動の有無で差が無いかな？
0632NAME IS NULL
2015/05/18(月) 07:18:27.73ID:???おはようございます。
キーの変更はありません。
0633NAME IS NULL
2015/05/18(月) 12:55:57.47ID:???答えにはならないけれど、ここがどうしても不思議だよね
0634隼人新聞社
2015/05/26(火) 16:28:37.37ID:n4ClT7vvこんなにある、創価員による破壊的狂気的犯行の数々。実際には新聞ＴＶにのらないだけでもっとある！次はあなたの番だ
●宅間守（在日部落）→大阪 附属池田小学校児童殺傷 。大量殺人犯 創価学会員の犯行 両親も創価学会員
８人殺害 １５人を殺傷。 朝鮮人部落出身。
●斉藤勇太→ＪＲ取手駅前バス無差別殺傷通り魔事件（取手バスジャック） 創価学会員の犯行
「通勤、通学客で混雑するバスの中で手加減せず無差別に襲っており、社会に大きな不安や衝撃を与えた結果は重大だ」
●酒鬼薔薇聖斗→ 東慎一郎（在日）神戸の首切り魔で酒鬼薔薇聖斗 神戸の首切り魔。生首を校門に飾る。２人殺害。創価学会員の犯行 大量殺人犯
●福田孝行（在日）→山口県母子強姦殺害 殺害後屍姦、乳児も殺害 大量殺人犯 創価学会員の犯行。裁判では屍姦は
生き返らせるための（創価流の）儀式だと供述 死刑判決
● 大芦明 →2011年 11月5日 大阪府堺市中区 隣人二名殺害事件。創価学会員の犯行 無期懲役
●八木茂 →埼玉・保険金殺人事件犯人 ２名殺害（平成12年）死刑判決 創価学会員の犯行
●武まゆみ→、埼玉・保険金殺人事件犯人 ２名殺害（平成12年）無期懲役 創価学会員の犯行
●森田考子→埼玉・保険金殺人事件犯人 ２名殺害（平成12年）共犯者で懲役13～15年の判決 創価学会員の犯行
●柏市連続通り魔殺傷事件X強盗殺人 創価学会員の犯行の犯行
●引寺利明 →マツダ宇品工場ファミリア暴走連続殺傷事件 引き殺しで1人死亡、11人を殺傷 創価学会員の犯行
●織原城二(金聖鐘) → ルーシー・ブラックマンさん事件 創価学会員の犯行 10人の女性に強姦又は強制わいせつ 内2人の女性が死亡
●山口芳寛 →熊本3才女児遺棄事件。レイプ 創価学会員の犯行。幼女に熱い視線、女児が大好き 強姦殺人無期懲役
●内柴正人→柔道金メダリスト（連続）強姦事件 （2009.5.15付 聖教新聞） 創価学会員の犯行
●アクリフーズ毒入り大量殺人事件 創価学会員の犯行
●リサイクルショップエース大量殺人事件 連続殺人！５人以上を殺して埋める 創価学会員の犯行
0635NAME IS NULL
2015/06/05(金) 17:17:41.60ID:msAAMg8hyum で aws linux に php5.6.9 と postgresql9.4.1 をインストールしたのですが、
phpinfo を見ると PostgreSQL(libpq) Version が 8.4.20 になっています。
開発環境として Mac にも php5.6.9 と postgresl9.3.5 をインストールしましたが、
そちらは phpinfo では PostgreSQL(libpq) Version は 9.3.5 になっています。
どうやって aws linux の方の PostgreSQL(libpq) を9.4.1にしたら良いのでしょうか？
0636NAME IS NULL
2015/06/05(金) 18:07:20.02ID:???最新使いたいときはビルドからやってるな、ソースから入れるのはダメ？
0637NAME IS NULL
2015/06/05(金) 18:20:43.83ID:???0638NAME IS NULL
2015/06/05(金) 18:23:52.53ID:msAAMg8h特に問題はなさそうだ、ということは調べたところ巷で言われてるみたいですね。
今回、phpから接続する先の postgresql は 9.4.1 なので問題はないのですが。
ただ、なぜ libpg だけが 8.4.20 になってしまうのか、が疑問でした。
Mac は問題ないのになぁ…
0639NAME IS NULL
2015/06/05(金) 18:28:58.43ID:???0640NAME IS NULL
2015/06/05(金) 23:29:56.63ID:???リポジトリ側でphpをmakeするとき、libpgがそのバージョンだったんだろうね。
新しいのが良いのであれば自分でmakeしないといけない。
0641NAME IS NULL
2015/06/06(土) 21:18:03.95ID:???0642NAME IS NULL
2015/06/07(日) 03:26:48.46ID:???正確にはextension差し替えればいい。
http://arpanet617.blog.fc2.com/blog-entry-18.html
ただ個別に入れるの面倒だし、yumでphp更新したときにエラーが出る可能性があるからお勧めはしない。
0643NAME IS NULL
2015/06/08(月) 13:27:50.29ID:???スタティックリンクかどうかなんて関係ないし
0644NAME IS NULL
2015/06/11(木) 11:52:15.90ID:???0645NAME IS NULL
2015/06/11(木) 12:11:14.71ID:???config.log の作成時刻からpostgres本体の作成時刻までの差は11分だな
VPSは一番安いコース
0646NAME IS NULL
2015/06/11(木) 12:47:54.89ID:???real 2m26.926s
user 2m10.206s
sys 0m14.643s
/proc/cpuinfoから抜粋：
model name : Intel(R) Core(TM) i7-3615QM CPU @ 2.30GHz
0647646
2015/06/11(木) 12:57:34.35ID:???real 3m59.812s
user 3m35.219s
sys 0m23.292s
/proc/cpuinfoから抜粋：
model name : Westmere E56xx/L56xx/X56xx (Nehalem-C)
cpu MHz : 2400.084
0648NAME IS NULL
2015/06/11(木) 22:49:17.11ID:???0649NAME IS NULL
2015/06/18(木) 17:27:41.53ID:???トアプリケーションが異常終了したり、
ネットワーク接続が切れたりすると、
バックエンドプロセスが残留しますが、
このプロセスを終了させたいのですが
良い方法はありませんか？
0650NAME IS NULL
2015/06/18(木) 17:39:42.09ID:???SELECT pg_cancel_backend(procID);
とか
0651NAME IS NULL
2015/06/18(木) 19:03:21.68ID:???どのプロセスがその状態に陥っているかを知りたい。
0652NAME IS NULL
2015/06/19(金) 10:53:17.78ID:???PostgreSQL、ゾンビでぐぐってみては
0653NAME IS NULL
2015/06/20(土) 08:23:46.04ID:???バックエンドプロセスが起動してるけど、何らかの理由でクライアントアプリケーションとのセションが無効になってしまっているプロセス。
Unix的なゾンビプロセスではないですよね。
ちなみに、PostgreSQL ゾンビでぐぐってみましたが、よく分かりませんでした。アタマに次のページが出てきたのですが。
http://blog.sakatam.net/2011/02/postgresql.html?m=1
pg_stat_activityビューで、一番古いプロセスを見つけようとしているだけで、セションが無効になったプロセスではないからです。
一番古いプロセスは、必要条件かも知れませんが、十分条件ではありません。
0654NAME IS NULL
2015/06/20(土) 08:28:52.86ID:???0655NAME IS NULL
2015/06/20(土) 14:52:14.62ID:???RACみたいなことはRACにしかできないよ
0656NAME IS NULL
2015/06/22(月) 10:51:20.69ID:???セッションが無効になってることをどうやって調べるの？
基本的に切れたら終了するでしょ
0657NAME IS NULL
2015/06/22(月) 11:48:02.35ID:???いや、正常にコネクションを終了したら、バックエンドプロセスは終了しますが、なんらかの理由でクライアントが突然いなくなると、バックエンドプロセスが残るのです。
たとえば、接続中の回線が切れたとか。あるいは、クライアントアプリケーションがコア吐いて終了するとか。
psqlを立ち上げて、ctrl-Zで終了すると、バックエンドプロセスが残ることが確認できます。
で、いろいろ調べてみたのですが、これ、外部からは分からないですね。
今やってるプロジェクト限定で、回線断発生時にはそのインタフェースに接続中のプロセスを殺すことにしました。
プロセスは、pg_cancel_backend()では消えてくれなく、pg_terminate_backend()する必要がありましたが。
0658NAME IS NULL
2015/06/22(月) 12:57:16.92ID:???0659NAME IS NULL
2015/06/22(月) 18:34:30.79ID:???> ctrl-Zで終了すると
ん？
0660NAME IS NULL
2015/06/22(月) 18:53:39.99ID:???0661646
2015/06/23(火) 10:58:49.38ID:???> psqlを立ち上げて、ctrl-Zで終了すると、バックエンドプロセスが残ることが確認できます。
Linuxのsh系の話だとしたら、ctrl-Zはsuspendだよ。
psで見れば、psqlの親プロセスがbashなどのshellだということがわかるはず。
0662NAME IS NULL
2015/06/23(火) 11:00:22.08ID:???0663NAME IS NULL
2015/06/23(火) 11:32:59.23ID:???そうなんですか？
プログラム組んで、そいつをkillしたときは、プロセスが消えてくれたと思ってたんですが、psqlは消えてくれなかったので、これが普通なんだと思っていました。
使える環境、root権限がないから、回線障害が起こせなくて。
LANケーブル抜こうにも、仮想マシン間の通信だったりして、それもムリだし。
0664NAME IS NULL
2015/06/23(火) 11:50:51.78ID:???> LANケーブル抜こうにも、仮想マシン間の通信だったりして、それもムリだし。
コマンドで停止すればいいじゃん。
0665NAME IS NULL
2015/06/23(火) 12:03:55.17ID:???一般ユーザでも、できるんですか？
psqlそのものを、killしたら、バックエンドプロセス消えたように見えます。
裏取したいんですが、どう調べればいいでしょう？
backend/libpq/pqcomm.c 辺りを見ているのですが、よう見つけません。
0666NAME IS NULL
2015/06/23(火) 13:21:00.14ID:???0667NAME IS NULL
2015/06/23(火) 13:54:41.21ID:???0668NAME IS NULL
2015/06/23(火) 14:16:10.09ID:???クライアントアプリケーション(C言語で開発)です。
まだ、開発には取りかかってないので、psqlを使って、接続の確認をしています。
0669NAME IS NULL
2015/06/23(火) 15:14:58.31ID:???0670NAME IS NULL
2015/06/23(火) 16:59:11.10ID:???0671NAME IS NULL
2015/06/23(火) 18:33:32.84ID:???> 一般ユーザでも、できるんですか？
よくわからんが、仮想マシンもrootで動かしてるのか？
rootになれない環境で、rootが動かす仮想環境内でDBが動いてる？
0672NAME IS NULL
2015/06/24(水) 07:54:32.41ID:???仮想マシンは、一般ユーザ権限で使っています。postgresユーザにさえなれれば、PostgreSQLの管理はできますので。
root権限は渡されてないです。
0673NAME IS NULL
2015/06/24(水) 08:09:55.98ID:???いつも使っているマシンでなく、別環境で、rootが使える環境を見つけましたので、簡単なプログラムでテストしてみました。
OSの設定は、不明。PQconnectdb()でkeepalive関連の指定なしにDBに接続して、PQsendQuery()でSQLコマンドを送った後、サーバ処理終了を待っている間に、インタフェースダウンすると、約2時間後にPQstatus()がCONNECTION_BADになりました。
クライアント側は、時間が掛かったことを除くと、ほぼ期待通りの動きをします。
サーバ側では、リンクダウンして14時間以上経った今でも、バックエンドプロセスは存在しています。
このプロセスは、殺したいですね。
0674NAME IS NULL
2015/06/24(水) 08:48:06.25ID:???keepaliveの設定により、クライアント側は、適切なタイミングで接続エラーが拾えるようになりましたが、問題はやはりサーバのバックエンドプロセスですね。
サーバは24時間運転するので、PostgreSQLの再起動はたぶん、拒否されるでしょうから。
ちなみに、使用するのはPostgreSQL 9.2.4です。これは、変えられない模様。9.2.11までの、プロジェクトで使っていると起こるであろう問題の修正点一覧作って提出したら、時間のムダって言われましたから。データ破壊とか、サーバダウンとかあるのに。
0675NAME IS NULL
2015/06/24(水) 10:56:05.90ID:???だからもしバックエンドプロセスが返事の送信をリトライしているならば、
クライアントが復活した時点でSEQが一致せずにサーバにはRSTが送られるはず。(で EPIPE)
何も送信しないなら、検出は難しいかも。TCPの上のレベルでハートビートするプロトコルが多いのはこれが理由かな。NAT環境だと尚更。
読むといいよ: http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-2.html
これを踏まえた上で…。
PostgreSQL プロトコル独自のハートビートって無いの？ ＞だれか
0676NAME IS NULL
2015/06/24(水) 11:19:54.80ID:???ローカルで検証できる環境作れよ。
0677NAME IS NULL
2015/06/24(水) 12:27:05.26ID:???残念ながら、それは難しいですね。
マシンがないのと、そもそもインターネットに接続できないので、勝手になにかを導入することはできないですね。
調べ物は、自前の携帯でやらざるを得ない。自席のPCからアクセスできるのは、manページと、PostgreSQLのHTMLのマニュアルだけ。
0678NAME IS NULL
2015/06/24(水) 13:38:50.80ID:???運用上は今まで問題なかったのですか。
0679NAME IS NULL
2015/06/24(水) 13:42:28.19ID:???DBの再起動すると、消えてくれるはずですので、それで問題でないのでは？
0680NAME IS NULL
2015/06/24(水) 13:51:54.88ID:???https://www.postgresql.jp/document/8.1/html/runtime-config-connection.html
tcp_keepalive_* を設定すればいいんじゃね？
0681NAME IS NULL
2015/06/24(水) 14:19:16.78ID:???なるほどーすごいですねー（棒
0682NAME IS NULL
2015/06/24(水) 14:31:20.91ID:???自宅でやれよ
何時間かあったら検証できるだろ
0683NAME IS NULL
2015/06/24(水) 15:33:13.09ID:???0684NAME IS NULL
2015/06/24(水) 16:08:04.84ID:???0685NAME IS NULL
2015/06/24(水) 16:46:11.71ID:???データベースに接続するようなアプリの開発をやってるなんて・・・
0686NAME IS NULL
2015/06/24(水) 17:46:08.34ID:???SIGTERMやSIGKILLじゃそれとはぜんぜん違った結果になるから、
その辺わかってないなら実機でやれと書いてたんだ。あまり興味を示されなかったからほっといたけど。
0687NAME IS NULL
2015/06/24(水) 18:39:38.96ID:???雰囲気も微妙だし絡みづらいわ
自分も同じような経験ある
クライアントはWindowsアプリでODBCドライバ使って接続してる
ユーザがアプリを強制終了したりするとバックエンドプロセスが残るので
サーバ側に任意のバックエンドプロセスをkill出来るようなウェブアプリを作って
必要に応じて手動でkillして対応してたわ
0688NAME IS NULL
2015/06/24(水) 19:23:10.55ID:???帰り際に確認したら、昨日のテストでクライアントがいなくなったバックエンドプロセスが24時間経っても残っていた。
postgresql.confに、特別にtcp keepaliveの設定しなくとも、OSの標準設定でTCPコネクションは切れてると思うけど、やっぱプロセス残るんだ。
#tcp keepaliveの検証やらなきゃならないと主張する人がいて。パラメータ取得して、システムコール呼んでるだけやから、OSの検証やるの？と聞いたが、検証しなきゃ納得しないといって、困った。
0689NAME IS NULL
2015/06/24(水) 19:25:51.37ID:???ああ、質問でしたか。見間違えてた。
現状のシステムはPostgreSQLなんか使ってません。
今回、新規にPostgreSQLを適用します。
#でも、9.2.4なんだな・・・
0691NAME IS NULL
2015/06/24(水) 20:25:10.57ID:???・pgpool pgbouncerのような接続プールを挟む
・pg_stat_activityとnetstatを照らし合わせて掃除するcron作る
のどっちかでとりあえず解決するんじゃないかな。
>>675
質問主の状態がわからないけど、idle状態で残り続けてる状況なら、クライアント復活からのRSTも見込めそうにない。
そも、同一IPアドレスで復活してくれるかどうかも怪しい。
ハートビートもこれまで聞いたことがないけど、
不特定多数のクライアントが直接接続するような設計を避けるのが常だから調べたことがないだけで実はあるのかも。
0692NAME IS NULL
2015/06/24(水) 22:44:00.02ID:???正式に聞くべきというのは、PostgreSQLのバージョンの件ですか？
別のプロジェクトでこのバージョンを使うのを決めた人たちに、今のバージョンは、問題があると進言して、中身も見ずに、これ作るのにどれだけ掛かったんですか？時間のムダです。と一考だにされず。
その本稼働していてるプロジェクトでは、障害多発。でも、バージョンは変えません。
いや、メジャーバージョンを変えようと言ってるわけではなく、マイナーバージョンを最新に上げようと言っただけなんですが。
検証してないから。バージョンアップで新しいバグが出てくるかもしれないから。
ついていけないので、今月末でこのプロジェクトから抜けますから、ハッキリいうと、もうどうでもいいのです。
ただ、いる間はできることはしようと。
0693NAME IS NULL
2015/06/24(水) 23:15:37.40ID:???アプリケーションを使うユーザは複数いますが、アプリケーション自体は同じマシンで動いてる複数のプロセスになりますので、同一アドレスから同一ユーザで複数のバックエンドプロセスが上がることになります。
システムは2重化されており、クライアントアプリケーションの動くマシン
は2台あり、どちらか(必ず一方のみ)から接続にきており、クライアントと
サーバの通信経路も2重化、どちらかのインタフェースに接続されます(どちら
にも接続が発生する可能性がある)。
DBサーバも2重化されており、ここはマ
スタ-スレーブのレプリケーションが動いており、クライアントアプリケー
ションは、マスタ側に接続しなければならないけど、マスタ-スレーブの関係
がひっくり返ることもあるという、素敵なシステムです。
たぶん、cronは使えません。サーバ間の時刻同期の仕組みも、ntpとかじゃな
く、独自ミドルウェアの機能でアプリケーションが同期させるようです。
仕様も決まってませんが、来月中には結合テストをやるらしいです。
0694NAME IS NULL
2015/06/24(水) 23:53:37.39ID:???コネクションプールの件は何でスルーしたの？ずっと、返事したいところだけ返事するスタンスだよね。
なんかプロジェクト内でも浮く理由はその辺にあると思う。
それに、今出てきた情報によると、実運用環境みなしでの実験できてないでしょ。
結合や運用に入っても結局あなたが気にしている問題は表面化することないと思うよ。
0695NAME IS NULL
2015/06/25(木) 06:38:07.86ID:???コネクションプーリングを求めてやってた訳ではないですが、pgpool-IIでの
検証とやらを昔やってて、性能が素のPostgreSQLより劣るということで不
採用になっています。
今の時点で新しい仕組みを入れるの
は、100%の確率で拒否されます。マイナーバージョンアップすら、拒否され
るんですから。
ちなみに、今やっているプロジェクトでは、クライアントプロセスは、最大
で31接続。たぶん通常は5プロセスもないのではないでしょうか。
しかも、クライアントとサーバは悪くても同一セグメントのLAN上に存在
し、ほとんどの場合同じ筐体内の別VMなので、正直回線障害はほとんど
起こらないと思います。
しかし、回線障害発生したときの仕組
みを作れと。なぜなら、今回の仕組みを横展開するからと。
今回の件も、具体的に発生することが見込まれて、それで困るから事前に対
策を打っておくというよりは、こんなことが起こるかもしれないよね、それ
に対して対応しててね、くらいのレベルのもので。他の観点から、この仕組
みだとこれこれこういった場合にこんなことが起こって、データが壊れるの
で対策しなきゃいけないんではないですか？というと、それは滅多に起こら
ないから、考えなくていい。運用でカバーする。運用はまだ考えてない。
てな具合ですから。
何を優先しなくてはならないかがハッキリしてなくて。
もちろん、今作ろうとしてるところに明文化された要求仕様といったものはありません。
0696NAME IS NULL
2015/06/25(木) 08:08:33.84ID:???tcp keepaliveの効果を検証するということで、まずはクライアント側で
PQconnectdbでkeepaliveの設定をいろいろ変えて時間を測っているのですが、
今回はどの設定にしようと、約15分でPQstatusがCONNECTION_BADになります。
同じプログラム、同じマシンで、その前はアイドル10秒、間隔10秒、リトラ
イ3回の設定で約1分で状態が変わったのですが。
前回と今回の違いはただ1点。前回は、サーバ側のインタフェースをダウ
ンさせていましたが、今回はインタフェースダウンから何秒でタイムアウ
トするかの時間を正確に測ろうと、クライアント側のインタフェースをダウ
ンさせていることです。
この違いで、条件変わりますか？
よく分からないなりに考えると、監視しているソケットのリンクが落ちてる
と、そもそもtcpコネクションがkeepalive送ることができなくなるよ
うな気もしますが。
状態が違うなら、これも考えに入れなきゃならないのか、あるいは対応できませんで済ましてみるか。
てか、そもそも普通はそんなこと考えないのか。
0697NAME IS NULL
2015/06/25(木) 10:08:30.60ID:???> PQconnectdbでkeepaliveの設定をいろいろ変えて時間を測っているのですが、
なんで、postgresql.confの設定を変えて調査しようと思わないの？
0698NAME IS NULL
2015/06/25(木) 10:50:07.57ID:???リンクダウンしてから、keepaliveがタイムアウトするまでの時間を測りたいのですが、サーバプロセスで測る方法ありますか？
何秒の単位でいいのですが。
なので、クライアント側で設定が効いてるのを確認して、サーバ側で同じ設
定で、リンクダウン後プロセスがなくなったことを確認できればいいかなと
考えています。
postgresql.confに設定してるのですが、なにかの手違いでshow tcp_なんちゃら
にすら反映されてないので、現時点ではバックエンドプロセス残りまくりな
んですが。
サーバ側を立ち上げ直せるタイミングで設定の見直しをします。
0699NAME IS NULL
2015/06/25(木) 10:55:13.65ID:???> リンクダウンしてから、keepaliveがタイムアウトするまでの時間を測りたいのですが、サーバプロセスで測る方法ありますか？
まずは、postgresql.confの設定が、クライアントロストの時にどう影響するのか調べるのが先決では？
> クライアント側で設定が効いてるのを確認して
え？
クライアントの接続時の設定と、サーバプロセスの設定は全く別では？
> サーバ側を立ち上げ直せるタイミングで設定の見直しをします。
だから、自分で環境作って試せって言ってるんだが。
0700NAME IS NULL
2015/06/25(木) 10:59:23.60ID:???> #tcp_keepalives_idle = 0 # TCP_KEEPIDLE, in seconds;
> # 0 selects the system default
> #tcp_keepalives_interval = 0 # TCP_KEEPINTVL, in seconds;
> # 0 selects the system default
> #tcp_keepalives_count = 0 # TCP_KEEPCNT;
> # 0 selects the system default
となってるけど、この"system default"が実際にはいくつなのか調べた？
で、この値を変更するとどうなるか調べた？
0701NAME IS NULL
2015/06/25(木) 11:02:09.80ID:???* クライアント側の問題によるリンクダウン
* サーバ側の問題によるリンクダウン
* クライアントアプリの突然死
では、それぞれサーバプロセスの振る舞いが違うかもよ。
0702NAME IS NULL
2015/06/25(木) 11:15:02.93ID:???全然一般的なPostgreSQLの話題から逸れてるだろ？
然るべきコンサルタント等に金払って技術支援してもらえよ
0703NAME IS NULL
2015/06/25(木) 11:29:05.51ID:???0704NAME IS NULL
2015/06/25(木) 11:38:10.86ID:???システムデフォルトは、
net.ipv4.tcp_keepalive_intval = 75
net.ipv4.tcp_keepalive_probes = 9
net.ipv4.tcp_keepalive_time = 7200
となっています。
postgresql.confに設定しないと、サーバプロセスが残りっぱなしになります。
2時間ちょいでタイムアウトしてもよさそうですが、メッセージを待っている
状態なのか、タイムアウトしてくれません。
postgresql.confに、
tcp_keepalives_idle = 10
tcp_keepalives_interval = 10
tcp_keepalives_count = 3
と設定してるのですが、psqlで確認しても設定されてないので、今はここらへんを調べてます。
ちなみに、今実行しているクライアントプログラムは、PQsendQueryが正常
に発行され、サーバからの処理完了のメッセージを待つタイミングでインタ
フェースダウンを起こしています。
サーバ側もクライアント側も、設定に従ってkeepaliveがタイムアウトすると思っているんですが。
0705NAME IS NULL
2015/06/25(木) 11:51:04.54ID:???正直、ここまで突っ込んでいくと、PostgreSQLのことをやっているの
か、OSのtcp/ipの実装を調べてるのかよく分からなくなります。
調べろと言った人は、単純に考えてるのか、プロセス残るのは、回線障害だ
けじゃなく、クライアントプロセス異常終了でも残りますよねというと、そ
れはまた別の問題やからと言ってくれます。
何を問題視してるのか？バックエンドプロセスが残っていて、使えるセショ
ンが減り、最終的にクライアントプロセスから接続できなくなるのが問題じゃないの？回線障害で残ったプロセスは問題でクライアントプロセス異常で残ったプロセスは問題にならないの？
0706NAME IS NULL
2015/06/25(木) 12:01:58.87ID:???クライアントだろうがサーバだろうが、やってることはsetsockopt()ですか
ら、設定が正しくと効いているかどうかという観点では、どちらで確認してもよいのでは？
ちなみに、今テストしてるマシン2台は、専有状態で使用しています。自分のテストプログラムが走っている最中にサーバリスタートしたら、テストプ
ログラムが死んでしまいます。
0707NAME IS NULL
2015/06/25(木) 12:37:37.95ID:???> クライアントだろうがサーバだろうが、やってることはsetsockopt()ですか
> ら、設定が正しくと効いているかどうかという観点では、どちらで確認してもよいのでは？
PostgreSQLのサーバプロセス(hoge/bin/postmaster, hoge/bin/postgres)が、通信異常時に
どう振る舞うかと、クライアントアプリの接続マネージャ的な何かの通信異常時の振る舞いには
違いがあるでしょ。
「設定」も、postmaster,postgresプロセスに関連するpostgresql.confの設定と、クライアントアプリ
が接続するときのパラメータは、別物。
> ちなみに、今テストしてるマシン2台は、専有状態で使用しています。自分のテストプログラムが走っている最中にサーバリスタートしたら、テストプ
> ログラムが死んでしまいます。
サーバリスタートって、postmasterの再起動だよ？
0708NAME IS NULL
2015/06/25(木) 12:42:04.07ID:???0709NAME IS NULL
2015/06/25(木) 12:45:03.83ID:???0710NAME IS NULL
2015/06/25(木) 13:05:41.50ID:???> ちなみに、今テストしてるマシン2台は、専有状態で使用しています。自分のテストプログラムが走っている最中にサーバリスタートしたら、テストプ
> ログラムが死んでしまいます。
うわ、このレベルだったのか。
この分じゃ、reloadのことも知らないんだろうなぁ。
0711NAME IS NULL
2015/06/25(木) 13:25:12.18ID:???TCPコネクションが、keepaliveのタイムアウトによって、切れるところまで
は、サーバだろうが、クライアントだろうが、一緒でしょ？
タイムアウトした後の振る舞いはプログラム毎に変わるやろうけど。
間違ってる？
そういう意味で、tcp keepaliveの設定は、サーバだろうが、クライアントだ
ろうが、変わらないと言っています。
実際、どちらも、setsockopt()で設定してますので。
サーバリスタート、もちろん、PostgreSQLのみのstop/startです。
0712NAME IS NULL
2015/06/25(木) 13:31:04.64ID:???ん？DBにアクセスしているプログラムがいるのに、DB再起動して無事なプログラムって簡単に作れるんですか？
あれ？このパラメータ、サーバ起動時のみ設定可能と書いてないということは、reloadで変更できる？
それでも、stop/startで有効になってなくて、今困っています。ほかのパラ
メータいじると変更が反映されるので、postgresql.confはこれでいいはずなんやけど。
0713NAME IS NULL
2015/06/25(木) 13:32:39.20ID:???> タイムアウトした後の振る舞いはプログラム毎に変わるやろうけど。
目下の問題は、サーバプロセス(hoge/bin/postgres)が残ることです。
postmaster,postgresプロセスが
何か異常を検知したときに、正常に処理が終了していないpostgresプロセスをどうするかは、
・postgresqlプロセス自身がエラーを検知し何か処理する（自分で死ぬとか）
・postmasterが子プロセスに対して何か処理する（シグナルを送るとか）
のどちらかしかありません。
で、実際はどうしてるのかを、実際にエラーを起こしてみて観察すべきではと言っています。
postmaster, postgresqlプロセスがどう振る舞うのかは、クライアント(アプリ)は関係ありませんね。
> サーバリスタート、もちろん、PostgreSQLのみのstop/startです。
じゃ、
> 自分のテストプログラムが走っている最中にサーバリスタートしたら、テストプ
> ログラムが死んでしまいます。
これは一体どういう意味？
0714NAME IS NULL
2015/06/25(木) 13:34:44.32ID:???> ん？DBにアクセスしているプログラムがいるのに、DB再起動して無事なプログラムって簡単に作れるんですか？
大部分の通信をするプログラムは、サーバが死んだって死なないのが普通でしょ。
httpサーバが死んでもブラウザはそのままだし、sshdが死んでもsshクライアントは死なない。
0715NAME IS NULL
2015/06/25(木) 13:36:14.02ID:???終了するまでずっと使い回すってやり方してるのか？
0716NAME IS NULL
2015/06/25(木) 13:42:41.66ID:???そういう作りもありっちゃありだが、connectionが切れたくらいでアプリが死ぬのはいかがなものか。
0717NAME IS NULL
2015/06/25(木) 14:03:09.77ID:???keepalive関係ないのに
0718NAME IS NULL
2015/06/25(木) 14:04:43.98ID:???0719NAME IS NULL
2015/06/25(木) 14:16:19.19ID:???0720NAME IS NULL
2015/06/25(木) 14:32:46.73ID:???> これこれこういった場合にこんなことが起こって、データが壊れるの
> で対策しなきゃいけないんではないですか？というと、それは滅多に起こら
> ないから、
通信周りのエラーリカバリ処理において、データが壊れることは滅多にどころか絶対に無い。
0721NAME IS NULL
2015/06/25(木) 14:50:18.76ID:???やりとり聞いておかしいと思わないのw
0722NAME IS NULL
2015/06/25(木) 14:50:51.41ID:???やりとり聞いておかしいと思わないのw
0723NAME IS NULL
2015/06/25(木) 14:54:16.35ID:???そんときバックエンドプロレスがゾンビさんになったら、どうすんの？
ほっとけばいいの？今までそんな事は問題にならなかったの？
って話かと。
0724NAME IS NULL
2015/06/25(木) 14:57:22.49ID:???0725NAME IS NULL
2015/06/25(木) 15:06:52.50ID:???エラーリカバリ処理と何の関係もない。
0726NAME IS NULL
2015/06/25(木) 15:16:59.24ID:???ゾンビプロセスは俺用語じゃないぞ
0727NAME IS NULL
2015/06/25(木) 15:19:49.29ID:???今回の話は、ゾンビプロセスの話じゃない
なのに「ゾンビが」みたいなこというと話が混乱すると言うことだ
0728NAME IS NULL
2015/06/25(木) 15:22:28.42ID:???んじゃ正しく言ってみろよ。
0729NAME IS NULL
2015/06/25(木) 15:41:03.57ID:???>>725の通り
postgresプロセスの終了処理をpostmasterが正しく行わなかったときに、postgresプロセスが
defunct状態になるのがゾンビプロセス
0730NAME IS NULL
2015/06/25(木) 15:50:23.62ID:???0731NAME IS NULL
2015/06/25(木) 16:00:30.42ID:???0732NAME IS NULL
2015/06/25(木) 16:15:05.44ID:???長時間残ったり、ゾンビプロセスになって残ったりなんて記憶にないんだけど、ありがちな話なのか？
0733NAME IS NULL
2015/06/25(木) 16:28:57.24ID:???実際は知らん
649 名前：NAME IS NULL[sage] 投稿日：2015/06/18(木) 17:27:41.53 ID:???
PostgreSQLのDBに接続中にクライアン
トアプリケーションが異常終了したり、
ネットワーク接続が切れたりすると、
バックエンドプロセスが残留しますが、
このプロセスを終了させたいのですが
良い方法はありませんか？
0734NAME IS NULL
2015/06/25(木) 16:32:38.45ID:???ただネットワーク構成とか環境によるからありがちかと言われると困るが
元質問者がスルーしたから話すことは何もない
0735NAME IS NULL
2015/06/25(木) 16:35:15.90ID:???0736NAME IS NULL
2015/06/25(木) 17:37:10.61ID:???シェルとcronで定期的にkill出来るようするには出来ないのでしょうか
0737NAME IS NULL
2015/06/25(木) 17:44:42.68ID:???0738NAME IS NULL
2015/06/25(木) 17:53:07.57ID:???0739NAME IS NULL
2015/06/25(木) 18:33:06.72ID:???cronは使えなかったんじゃないのか
0740NAME IS NULL
2015/06/25(木) 18:37:48.75ID:???> コネクションプーリングを求めてやってた訳ではないですが、pgpool-IIでの
> 検証とやらを昔やってて、性能が素のPostgreSQLより劣るということで不
> 採用になっています。
コネクションプールをはさむことにより、バックエンドがidleのまま残り続けることを解消できるんだけど、
まぁ採用されないならどうでもいい。
0741NAME IS NULL
2015/06/25(木) 20:36:29.02ID:???> クライアントプロセス異常終了でも残りますよね
残りましたか？
0742NAME IS NULL
2015/06/25(木) 21:07:18.71ID:???0743NAME IS NULL
2015/06/25(木) 21:30:48.60ID:???FIN パケットとかも送れないからね
サーバー側のプロセスはコマンドを待ってる時間の方が長いからこういう状態になるとずっと待ち状態になることが多い
なので Keepalive の指定があって普通にディフォルトで使ってりゃそのうちサーバー側のプロセスが相手と通信できないことに気付いて終了するはず
単になんか変なことをやらかしてるか、実はちゃんと動いてるのに勘違いして騒いでるだけだと思う
0744NAME IS NULL
2015/06/25(木) 21:32:48.26ID:???0745NAME IS NULL
2015/06/25(木) 21:43:05.68ID:???なんかめんどくさい奴だから仕事の邪魔にならないように適当な課題与えてるとかかもな w
0746NAME IS NULL
2015/06/25(木) 22:50:22.53ID:???正しく終了するかどうかに集約されてると思うんだけど、質問主の環境ではどうなってるの。
0747NAME IS NULL
2015/06/25(木) 23:08:16.19ID:???0748NAME IS NULL
2015/06/26(金) 04:53:07.81ID:???0749NAME IS NULL
2015/06/27(土) 02:44:07.11ID:???0750NAME IS NULL
2015/06/27(土) 17:01:45.09ID:???0751NAME IS NULL
2015/06/29(月) 08:16:19.53ID:???keepalive効いてるようには見えません。
1. postgresql.confに設定した値が、プロセスに反映してない(showコマンドで確認しても、0)
2. システムデフォルトでタイムアウトするだろう時間が経っても、バックエンドプロセスは残ったまま
という状態です。
1.の問題は、postgresql.confの他の値を変更して再起動すると反映されてい
る、keepaliveの設定に文字をしていするとpostgresql.conf読み込みエラーに
なることから、読み込んだ後に値を保持設定するところで問題がないかと探
している状況です。
別のマシンでも、keepaliveの設定が反
映されてないので、単純な環境の問題ではないと思ってるのですが、OS環境
とか、ビルド環境とか自分でやった訳じゃないので、環境に問題なしとは言
い切れませんが。
2. の方は、クライアント側でのkeepalive設定は問題なく効いている
ので、OS側の問題じゃなく、PostgreSQLでどう捌いてるかの問題なのかなと思います。
クライアント側のテストをしていて、分かったのですが、サーバ側のイ
ンタフェースダウンを起こしたときは問題なくタイムアウトしてくれるので
すが、クライアント側のインタフェースをダウンさせた場合は、keepaliveの
設定が効いてくれず、どんな設定だろうが15分30秒ほどタイムアウトに時間
が掛かると言うことです。
これの原因は、どこにあるのでしょうか？
0752NAME IS NULL
2015/06/29(月) 09:54:36.50ID:???0753NAME IS NULL
2015/06/29(月) 10:15:42.60ID:???> クライアント側のテストをしていて、分かったのですが、サーバ側のイ
> ンタフェースダウンを起こしたときは問題なくタイムアウトしてくれるので
> すが、クライアント側のインタフェースをダウンさせた場合は、keepaliveの
> 設定が効いてくれず、どんな設定だろうが15分30秒ほどタイムアウトに時間
> が掛かると言うことです。
それ、>>701で指摘済みなんだが。
あと、自分で小さいtcpサーバ書いて、挙動を確かめる/調べてみようとか思わないの？
まあ、ググって情報集めたり、本本でもいいけど。
0754NAME IS NULL
2015/06/29(月) 10:58:24.87ID:???忘れた？
0755NAME IS NULL
2015/06/29(月) 11:37:07.10ID:???挙動が違うということは、理解してましたが、どう振る舞うかまでは分からなかったので。
今回やってるのは、ifconfig使ったリンクダウンですが、それじゃ、LANインタフェースボードの物理故障が起こったときは、とか中々シミュレーションしにくいケースどうするかとか、難しいですね。
tcpサーバ書いて実験するより、OSのドライバ周りを調査する方が確実と思えますが、そんな時間はありません。
今朝、また色々と横槍が入ってきて、回線エラーが起こったら、(アプリ
ケーションに戻さずに)アクセスインタフェースで生きてる回線に接続し
て、後続処理できるようにとか言っていますので、勝手にしてくれ、状態です。
ま、この現場明日までしかいないので。後は、別の人がやってくれるでしょう。
0756NAME IS NULL
2015/06/29(月) 13:51:06.15ID:???>ケーションに戻さずに)アクセスインタフェースで生きてる回線に接続し
>て、後続処理できるようにとか言っていますので、勝手にしてくれ、状態です。
馬鹿が馬鹿を指示して振り回し、振り回された俺たちはw
0757NAME IS NULL
2015/06/29(月) 21:25:23.82ID:???安価つけるなら、話を広げる前にまず>>746の回答してほしい。
> クライアント側のテストをしていて、分かったのですが、サーバ側のイ
> ンタフェースダウンを起こしたときは問題なくタイムアウトしてくれるので
> すが、クライアント側のインタフェースをダウンさせた場合は、keepaliveの
> 設定が効いてくれず、どんな設定だろうが15分30秒ほどタイムアウトに時間
> が掛かると言うことです。
これはつまり、行ったテストの範囲では、
前に言っていたpostgresプロセスが丸一日以上残るようなことにはならなくなったということでよろしいか。
0758NAME IS NULL
2015/06/29(月) 21:28:19.68ID:???こんなやさしいテストするよりもクライアント側のケーブル抜くほうがいい。
あともちろんパケットも見てんだよね？
0759NAME IS NULL
2015/06/29(月) 21:38:50.95ID:???0760NAME IS NULL
2015/06/29(月) 22:14:05.24ID:???0761NAME IS NULL
2015/06/29(月) 23:22:20.44ID:???そのクライアントとクロスケーブルでつないでwポスグレデフォインストルして
keepaliveのとこだけ変えて、んでもって繋がったら、ケーブル抜くとすぐわかると
思うんだけどなぁ。
難しいのかなぁ。
0762NAME IS NULL
2015/06/30(火) 07:44:28.05ID:???昨日の時点で、25日および26日にテストしたバックエンドプロセスは残り続けています。
もちろん、クライアントプログラムはとっくに終了しています。
0763NAME IS NULL
2015/06/30(火) 07:46:12.26ID:???VMの間でテストしてますから、この環境には、ケーブルなんてないんです。
0764NAME IS NULL
2015/06/30(火) 07:56:44.37ID:???リレー？
ハブとかルーターとかの用語ぐらい覚えてから話に加わってくれ
リンクダウンの検出は Keepalive とは別の話だからクロスケーブル直結のテストはほとんど意味がない
>>762
> 昨日の時点で、25日および26日にテストしたバックエンドプロセスは残り続けています。
それ以降の奴は残ってないのか？
て言うか、設定変更したらサーバープロセスすべて終了させて再起動するのは常識だと思うが
0765NAME IS NULL
2015/06/30(火) 08:00:42.94ID:???テスト環境というか、ここの会社全体がインターネットアクセスできないんです。
show tcpなんとかやっても、値は3つとも0でした。システムデフォルトを利用する設定ですね。postgresql.confにkeepaliveの設定をしてもこれは変わらず。
0766NAME IS NULL
2015/06/30(火) 08:10:00.52ID:???手で書き写して貼ればいいだろ
はっきり言ってお前の言うこと当てにならないと思ってるんだから、余計なことやらずに言われたことしなさいよ
0767NAME IS NULL
2015/06/30(火) 08:15:03.02ID:???手で書き写すことと、報告した内容と何が違うんですかね？
0768NAME IS NULL
2015/06/30(火) 08:19:25.12ID:???設定は木曜日にpostgresql.confを変更して以来変えてないので、サーバの再起動はしてません。
モノは試しと、Linux自身のkeepalive設定をsysctlで変更したのですが、状況は変わらず。
昨日は、触ってません。
0769NAME IS NULL
2015/06/30(火) 08:27:48.13ID:???今、tcpdump動かしてみたんですが、50マイクロ秒毎にloginプロセスがackを送り合っていて、とてもじゃないけど、見てられません。
今の環境は、
pc -> ゲートウェイ -> Xen Dom0 -> PostgreSQLサーバ
と言った感じでアクセスしてるので。
パケット解析は、昔snifferで、Windows NT 3.5 ServerとWindows 3.1クライアントで、dhcpがうまく動かないのを調査して以来してません。
0770NAME IS NULL
2015/06/30(火) 08:48:40.33ID:???ああ、うちの部下にもいるわ
こう言うごたく唱えて言われたことしない奴
まあ、あとは勝手にしろって話だな
0771NAME IS NULL
2015/06/30(火) 09:26:43.30ID:???0772NAME IS NULL
2015/06/30(火) 11:49:52.03ID:???> パケット解析は、昔snifferで、Windows NT 3.5 ServerとWindows 3.1クライアントで、dhcpがうまく動かないのを調査して以来してません。
なんだ、じじいか
0773NAME IS NULL
2015/06/30(火) 12:31:33.19ID:???0774NAME IS NULL
2015/06/30(火) 16:55:04.75ID:???0775NAME IS NULL
2015/06/30(火) 17:29:17.33ID:???0776NAME IS NULL
2015/06/30(火) 18:51:41.42ID:???他人からはこう見えるのだなぁと思い、気持ちを引き締めました。
ありがとう質問主。
0777NAME IS NULL
2015/06/30(火) 18:54:54.69ID:???ちょっとでも知識あったら
> 50マイクロ秒毎にloginプロセスがackを送り合っていて
なんて言わないよ
0778NAME IS NULL
2015/06/30(火) 18:59:17.21ID:???ケーブル抜くと50マイクロ秒後にはコネクション切れるね。
0779NAME IS NULL
2015/06/30(火) 19:20:28.67ID:???TCP だとリトライとかもあるから、50μs でセッション切れる訳じゃないけどね
まあ、そういう問題じゃなくて tcpdump とかのパケットをチラ見して login プロセスとか言い切っちゃうところとか色々思い込みが激しすぎる
マジでこう言う調査に向かない人だと思う
0780NAME IS NULL
2015/06/30(火) 22:40:53.36ID:???0781NAME IS NULL
2015/06/30(火) 22:45:13.20ID:???見つけたら早めに隔離するんだぞ。
0782NAME IS NULL
2015/07/03(金) 10:22:00.29ID:???0783NAME IS NULL
2015/07/03(金) 22:52:19.05ID:Kg1mNEJZ週一回、本番用のデータをテスト用に突っ込むのですが、
テスト用のデータベースに書いた部分は維持したいと
要望がありました。
ポスグレの機能だけで、こういうことは
可能でしょうか？
0784NAME IS NULL
2015/07/03(金) 23:05:09.08ID:???あなたとは死んでも本番したくないわ
0785NAME IS NULL
2015/07/03(金) 23:13:10.48ID:???0786NAME IS NULL
2015/07/04(土) 01:35:15.93ID:???0787NAME IS NULL
2015/07/04(土) 18:42:39.90ID:???それを足がかりに調べる人もいるだろうなぁ。
0788NAME IS NULL
2015/07/04(土) 21:58:47.39ID:???0789NAME IS NULL
2015/07/12(日) 23:22:32.62ID:???ある整数値を除算した結果(100/10.0等)が、
例えば、
10.0 の場合は、 '10'
10.5 の場合は、 '10.5'
というように出力したいのですが、to_charだけでは難しいでしょうか？
まず剰余を求めて、それとcase文を組み合わせればできるのですが…
0790NAME IS NULL
2015/07/20(月) 08:41:53.43ID:???キー値を更新して値が変わったら無理だろ。
問題になるのは「キーを更新」、「同じ行を違うタイミングで更新」等なので、まずデータの整合性が取れるのかを確認かな
0791NAME IS NULL
2015/09/24(木) 23:12:53.56ID:???Twitterのストリーミングapiのjsonをjsonbに生データで突っ込んで、後からビューを使って情報を引き出したいと思ってるんだけど。
0792NAME IS NULL
2015/09/25(金) 07:32:39.23ID:???ビューはクエリの短縮名に過ぎないからな
マテリアライズド・ビューならできたっけか？
0793NAME IS NULL
2015/09/25(金) 10:18:24.01ID:???Viewにインデックスを張るんじゃなくて、元テーブルに張るのはどう？
http://www.atmarkit.co.jp/ait/articles/1409/04/news005_2.html
0794NAME IS NULL
2015/09/25(金) 15:29:37.51ID:???MSSQLならできるというのがうらやましかったので。
0795NAME IS NULL
2015/09/25(金) 16:08:56.42ID:???0796NAME IS NULL
2015/09/25(金) 16:42:28.11ID:???0797NAME IS NULL
2015/09/25(金) 17:23:02.83ID:???ttps://www.postgresql.jp/document/9.3/html/rules-materializedviews.html
0798NAME IS NULL
2015/09/25(金) 17:32:17.36ID:???定期的にTruncateして作り直してる読み込み専用のテーブルがあるんだけど
コレにしたらREFRESHで済むんかな
0799794
2015/09/25(金) 17:38:55.42ID:???0800NAME IS NULL
2015/09/28(月) 13:18:25.62ID:???それとは別にpostgres.exeが10秒毎くらいにプロセス生成→消滅を繰り返している。
この件について原因と対策知っている方いますか？
windows7(64bit) postgresql9.2(x86)
0801NAME IS NULL
2015/09/28(月) 13:25:22.05ID:???原因と対策って、その状態が異常だと思ったの？
0802NAME IS NULL
2015/09/28(月) 13:34:26.95ID:???DBアクセス何もしてないのに？
0803NAME IS NULL
2015/09/28(月) 13:57:38.52ID:???今手元の開発マシン(Linux)を見たら、8個のプロセスが動いてた。
/usr/pgsql-9.2/bin/postmaster -p 5432 -D /var/lib/pgsql/9.2/data
postgres: logger process
postgres: checkpointer process
postgres: writer process
postgres: wal writer process
postgres: autovacuum launcher process
postgres: archiver process last was 00000001000000000000007C
postgres: stats collector process
Windowsも似たようなもんじゃないの？
0804NAME IS NULL
2015/09/28(月) 14:41:11.07ID:???status collector なんてあったっけ？
0805NAME IS NULL
2015/09/28(月) 15:11:39.73ID:???https://www.postgresql.jp/document/9.2/html/monitoring-stats.html
postgresql.confのtrack_なんちゃらを有効にすると起動されるみたい。
0806NAME IS NULL
2015/09/28(月) 16:43:38.53ID:???0807800
2015/09/29(火) 02:59:16.50ID:???プロセスが６つで、生成を繰り返すようなプロセスは確認されずでした。
明日もう一度会社でDBアクセスなしで確認してみます。
会社と自宅のpostgresql.conf比較してみます。
>>803のようにwindowsでプロセスの内容確認すること出来ませんかね？
>>803 わざわざ確認ありがとうございます。
0808800
2015/09/29(火) 03:01:13.99ID:???けど、１～５分に１回位で、時間間隔がバラバラでした。
0809NAME IS NULL
2015/09/29(火) 11:32:22.20ID:???定期的に生成されて状態チェックしてるんだろ
正常な動作だよ
0810NAME IS NULL
2015/09/29(火) 12:04:40.02ID:???0811NAME IS NULL
2015/11/04(水) 23:11:25.53ID:zvwt6tQ90812NAME IS NULL
2015/11/05(木) 00:32:35.47ID:???0813NAME IS NULL
2015/11/05(木) 19:35:57.39ID:???0814NAME IS NULL
2015/11/05(木) 21:20:16.42ID:???0815NAME IS NULL
2015/11/13(金) 00:13:30.47ID:???0816NAME IS NULL
2015/11/14(土) 16:22:17.03ID:YndhxX/W例えば、
CREATE TABLE test1(
id smallint,
field1 integer,
field2 text,
CONSTRAINT pkey PRIMARY KEY(id)
);
CREATE TABLE test2(
id smallint,
field1 integer,
field2 text,
CONSTRAINT pkey PRIMARY KEY(id)
);
を実行すると２つ目のCREATE TABLEが失敗します。
ドキュメントの情報スキーマのページには重複できるっぽいことが書かれてるんですけど、読み違えてますかね？
http://www.postgresql.jp/document/9.4/html/information-schema.html
データベースのバージョンは9.4.5です。
0817NAME IS NULL
2015/11/14(土) 18:54:59.24ID:???> を実行すると２つ目のCREATE TABLEが失敗します。
エラーメッセージも書かないと言うことは、釣りだな
スルーでいい
0818816
2015/11/15(日) 11:30:05.33ID:???失礼しました。
先述のコマンドをpsqlで入力、実行すると２つ目のCREATE TABLEで
ERROR: リレーション"pkey"はすでに存在します
というメッセージが表示されるという状況です。
テーブルを作成しようとしているスキーマはpublicスキーマです。
0819NAME IS NULL
2015/11/15(日) 12:14:53.90ID:???よく知らんけど
技術的には、PRIMARY KEY は単なる UNIQUE と NOT NULL の組み合わせです。
しかし、プライマリキーであることは他のテーブルがその列集合を一意な行識別子とみなせることを意味するので、列集合をプライマリキーと特定すると、スキーマ設計に関するメタデータを提供することになります。
http://www.postgresql.jp/document/9.4/html/sql-createtable.html
って書いてるので、とりあえず unique でやってみれば？
0820NAME IS NULL
2015/11/15(日) 12:44:59.54ID:???INDEX名は無理
UNIQUEでも同じかと
\di に出てくる奴はだめだね。
0821816
2015/11/15(日) 14:48:59.77ID:???\di を実行すると、名前列にpkeyがありました。
インデックス名が重複するとDROP INDEXが困るということでしょうか？
でも、そう考えると何となく理解できました。
勉強になりました。ありがとうございます。
0822NAME IS NULL
2015/11/16(月) 13:33:52.43ID:???http://jobinjapan.jp/cate/
全掲載求人109,160件の平均最低月給195,800円
PostgreSQLの求人 の平均最低月給230,400円
http://jobinjapan.jp/job-listing/keyword-postgresql.html
どんなもんだい！
0823NAME IS NULL
2015/11/16(月) 18:28:21.64ID:???0824NAME IS NULL
2015/12/08(火) 13:00:18.50ID:ptpZiaSaON CONFLICT句はいろいろと楽しめそうだ。SKIP LOCKED もついに来たか感がある。
GROUPING SETSもいいね！
ROW LEVEL SECURITY ってのは俺の使用目的では使いそうもないけど便利そうだな。
0825NAME IS NULL
2015/12/08(火) 13:10:25.39ID:???UPSERTとGROUPING SETSが来たらこれで本当にもう機能的にはMySQLに劣る要素が無いな。
0826NAME IS NULL
2015/12/08(火) 13:25:41.33ID:???ピジプーもよろしく
0827NAME IS NULL
2015/12/08(火) 15:07:20.82ID:ptpZiaSaすまんすまん。
0828NAME IS NULL
2015/12/11(金) 18:42:09.85ID:B7jWxD/A0829NAME IS NULL
2015/12/11(金) 23:45:59.35ID:???0830NAME IS NULL
2015/12/18(金) 04:58:46.13ID:???0831NAME IS NULL
2015/12/18(金) 10:13:00.06ID:???0832NAME IS NULL
2015/12/18(金) 10:44:33.86ID:???0833NAME IS NULL
2015/12/19(土) 11:42:47.21ID:kj2MyZObそういうことが簡単にできないから、工程というものがあるんだよ。
0834NAME IS NULL
2015/12/19(土) 13:11:52.52ID:???0835NAME IS NULL
2015/12/19(土) 15:19:31.49ID:SAIbB+7Z移行時に問題が起こって、切り戻す手順を考えてないのか？
移行後の検証に性能確認を入れてあれば、切り戻し判断をして戻せる。
ただそんな性能の問題で切り戻すのは、もともと性能テストをしていない、性能を十分考慮していないだけなので、プロジェクトとしては、許可しない。
0836NAME IS NULL
2015/12/19(土) 20:12:51.50ID:???0837NAME IS NULL
2015/12/19(土) 20:25:41.63ID:???0838NAME IS NULL
2015/12/20(日) 11:11:39.92ID:???pgsql.9.2.2とかpgsql.9.4.2 とかにインストールして使うときは pgsql にリンクしてる
0839NAME IS NULL
2015/12/20(日) 18:11:31.18ID:???0840NAME IS NULL
2015/12/20(日) 18:12:53.49ID:???0841NAME IS NULL
2015/12/21(月) 12:08:12.80ID:???9.3.1 initdbでは--encoding=EUC-JP --no-locale
この環境でcreatedbで--encoding=UTF8で作成したDBにPHPでそのままUTF8コードinsertしたら
「EUC-JPの範囲外じゃ」と怒られました
んで、pg_set_client_encodingでUTF8宣言したら、素直にinsertできたのですが、
createdbで--encoding=UTF8と宣言作成したのに、何故わざわざpg_set_client_encodingで
UTF8だよん、と教えないとだめなんでしょうか？ 下らない質問ですみません
0842NAME IS NULL
2015/12/21(月) 13:38:02.73ID:???clientはアクセスする側のエンコード
本来なら両者は不一致でも構わない、むしろその環境に合わせて変換してくれる
0843NAME IS NULL
2015/12/22(火) 07:11:53.47ID:???全体設定 → initdb時に自動的に作られる conf を参照する
DB毎設定 → created後、自前で設定が必要
みたいな扱いなんじゃないだろうか
0844NAME IS NULL
2015/12/22(火) 10:46:40.60ID:???0845NAME IS NULL
2015/12/22(火) 10:50:02.68ID:???0846NAME IS NULL
2015/12/22(火) 11:54:29.70ID:???そのつもりだった
database全体に適用される規定値
0847NAME IS NULL
2015/12/22(火) 12:55:54.84ID:???postgresqlのドキュメントはいつも最新の和訳があるので学習しやすいですね
和訳しているかたに感謝します
0848NAME IS NULL
2015/12/22(火) 23:51:32.68ID:???initdb時の指定エンコードで、createdbにエンコード指定しなければデフォでinitdb時の指定エンコードＤＢが（見た目）作成されますよね
疑問だったのは、createdbにクライアントエンコード指定してＤＢ作って、見た目そのエンコードのＤＢできたのに、
insert前に再度クライアントエンコード指定しないとエラー、というのが解せなかった、のです
Name | Owner | Encoding | Collate | Ctype |
-------------+----------+----------+---------+-------
db1 | hoge | EUC_JP | C | C |
db2 | hoge | UTF8 | C | C |
initdbのクライアントエンコーディングがEUC-JPなので、createdb db1なら上記のDBができ、db1にはそのまま
EUC-JPでinsertできますが、db2はinsert前にpg_set_client_encodingでUTF8指定しないとエラー
てっきり、そのままクライアントエンコードUTF8でdb2にinsertできる、と思ったものですから・・・
じゃぁ、上の一覧のEncoding「UTF8」って何の意味？と思った次第です 当然pg_dump_all もエラーになります
「このDBの中はUTF8ですよー」、って見た人に教えてるだけなんですねｗ
0849NAME IS NULL
2015/12/23(水) 06:09:33.52ID:???> createdbにクライアントエンコード指定してＤＢ作って
だから～、それ「クライアント」エンコードの指定じゃないだろ
0850NAME IS NULL
2015/12/23(水) 08:51:00.02ID:???あぁ、ごめんなさい 確かに
--encoding=encoding このデータベース内で使用する文字符号化方式を指定します
となっていますね
0851NAME IS NULL
2015/12/23(水) 18:51:28.02ID:???英日翻訳ができる人を対応に向かわせたら中国語で話されて戸惑ったみたいなもん
0852NAME IS NULL
2015/12/23(水) 20:30:48.89ID:???0853NAME IS NULL
2016/01/08(金) 00:12:30.13ID:???http://www.postgresql.org/about/news/1636/
0854NAME IS NULL
2016/01/08(金) 01:51:39.16ID:???待ってた
0855NAME IS NULL
2016/01/08(金) 11:42:27.12ID:???0856NAME IS NULL
2016/01/08(金) 12:47:24.15ID:???0857NAME IS NULL
2016/01/08(金) 13:21:58.96ID:???もう使ってる
0858NAME IS NULL
2016/01/08(金) 16:46:18.35ID:???0859NAME IS NULL
2016/01/08(金) 18:10:51.54ID:???0860NAME IS NULL
2016/01/08(金) 23:36:19.80ID:???メイクの途中でコンパイルが止まったように見えて一瞬びっくりした。
結局 テストもオールパス
>>859
upsertとかカラム単位の可視属性とかブリンとかてんこ盛りっすよ。
結構 いきつくとこまで来たのかも。
0861NAME IS NULL
2016/01/09(土) 20:15:12.23ID:???psql: FATAL: could not write init file
このエラーはどう言った状況で起きるのでしょうか
0862NAME IS NULL
2016/01/09(土) 20:36:57.05ID:???0863NAME IS NULL
2016/01/09(土) 21:34:13.42ID:???0864NAME IS NULL
2016/01/09(土) 22:03:59.85ID:???パラレルクエリという大物が残っている・・・
これが実装されたら10.0になるんだろうか。
>>863
分野が違うから併存していくんじゃないかなあ。
0865NAME IS NULL
2016/01/09(土) 22:39:34.95ID:???シェアも今はどうなのかわからない。
0866NAME IS NULL
2016/01/10(日) 20:14:45.89ID:???「セキュリティ証明書の有効期限が昨日付けで切れています。」
と言われます。
どうしたらいいですか？
0867NAME IS NULL
2016/01/11(月) 10:21:00.20ID:???2016年1月10日 7:59:57 で切れてるね
0868NAME IS NULL
2016/01/23(土) 10:33:31.47ID:TP7jF3P70869NAME IS NULL
2016/01/23(土) 13:18:22.43ID:???0870NAME IS NULL
2016/01/30(土) 18:32:23.42ID:???これから mysql は消滅方向ということなのかな・・・
0871NAME IS NULL
2016/01/31(日) 02:53:21.01ID:???0872NAME IS NULL
2016/01/31(日) 11:11:00.57ID:???自己レス
Let's Encrypt に切り替えてるな
うちもコレ使ってるわｗ
0873NAME IS NULL
2016/02/02(火) 18:00:43.45ID:???0874NAME IS NULL
2016/02/10(水) 15:24:44.30ID:???ARRAY['cat', 'dog', 'bird', 'sheep']
dogが来たら、'cat', 'dog'を返す。birdが来たら、'cat', 'dog', 'bird'を返す。
というように要素番号が下のものを全て取得することは出来ませんでしょうか？
0875NAME IS NULL
2016/02/10(水) 15:56:06.26ID:???できません。
0876NAME IS NULL
2016/02/10(水) 16:18:15.09ID:???0877NAME IS NULL
2016/02/10(水) 16:24:47.25ID:???そんなことデータベース側でやらなくて済むようなテーブル設計に変更できるなら、今しといた方がいいよ
0878NAME IS NULL
2016/02/10(水) 17:03:35.77ID:???ただ今回は微妙に異なる３つの指標を一つにまとめたことで、どうしても一部にしわ寄せが来てしまいました。
とりあえず関数を作成することにします！
0879NAME IS NULL
2016/02/10(水) 17:17:53.65ID:???9.5なら arr [ 1 : array_position( arr, 検索条件 ) ]
それ以前だと array_position() が提供されてないから unnest() で自作かな
0880NAME IS NULL
2016/02/10(水) 17:36:01.05ID:???9.5は本当に良作ですね。
0881NAME IS NULL
2016/02/10(水) 17:48:52.06ID:???0882NAME IS NULL
2016/02/11(木) 10:36:26.27ID:???0883NAME IS NULL
2016/02/11(木) 11:14:03.27ID:???けいれい！
なおれ！
かいさん！！
0884NAME IS NULL
2016/02/11(木) 11:28:27.05ID:???0885NAME IS NULL
2016/02/11(木) 12:58:18.17ID:???プログラミング言語とみると配列内検索はあって当然だったともいえる
0886NAME IS NULL
2016/02/11(木) 21:25:52.22ID:???ままは変２
ぱぱは変３
もしもし あなた変態ですよ。
0887NAME IS NULL
2016/02/12(金) 08:22:51.26ID:???0888NAME IS NULL
2016/02/12(金) 08:50:25.14ID:???なはなは
0889NAME IS NULL
2016/02/12(金) 18:10:23.31ID:???9.5は本当に良作っていう根拠を教えて。
0890NAME IS NULL
2016/02/12(金) 18:36:15.26ID:???0891NAME IS NULL
2016/02/12(金) 20:06:44.78ID:???0892NAME IS NULL
2016/02/13(土) 18:57:19.35ID:HtX8r0Z00893NAME IS NULL
2016/02/13(土) 19:00:13.43ID:HtX8r0Z0パーティション化方式は、なんとかしてほしい。
0894NAME IS NULL
2016/02/13(土) 19:16:29.81ID:???なんだいそれわ ググればわかる？
0895NAME IS NULL
2016/02/13(土) 19:46:52.59ID:HtX8r0Z0うん、ググればわかる。
PostgreSQLのパーティション化がアカンところ
・構文として、パーティション化がサポートされてなく、定義が直感的でない。
(継承機能の応用で無理やり実現している)
・パーティションを跨がるUPDATEができない
・パーティション数が増えると、プラン作成時間が線形に増加する。
他にもいろいろあるけど、とりあえず大きいのは、この3つ。
0896NAME IS NULL
2016/02/13(土) 21:52:36.09ID:???はぁ 勉強させていただきます
0897NAME IS NULL
2016/02/14(日) 13:43:46.03ID:???0898NAME IS NULL
2016/02/14(日) 19:56:10.82ID:???関東ではパンティーがションベン臭いということだ。
0899NAME IS NULL
2016/02/18(木) 08:03:55.92ID:???0900NAME IS NULL
2016/02/18(木) 13:03:55.18ID:???0901NAME IS NULL
2016/03/21(月) 20:18:42.16ID:???0902NAME IS NULL
2016/03/27(日) 03:18:14.56ID:SMb8cbIq以下のようなSQL文で抽出する際、内部では、
LEFT JOINで結合されたテーブルのようなものが一度生成され、
それに対してWHEREによる抽出が行われるのでしょうか？
もしそうだとすれば、
例えば、fooに10,000件あり、
fooのnameに対応するbarのnameが平均100件あったとすると、
内部で生成されるテーブルのようなものは100万件保持することになります。
SELECT * FROM foo \
LEFT JOIN bar ON foo.name = bar.name \
WHERE foo.id = 4;
もしこの仮説が正しいならば、
WHEREで抽出してからのほうが速い気がします。
例えば以下のようなSQL文です。
SELECT * FROM \
( SELECT * FROM foo AS xxx WHERE id = 4 ) AS xxx \
LEFT JOIN bar ON xxx.name = bar.name \
実際のところどうなんでしょうか？
後者のほうが速いのでしょうか？
0903NAME IS NULL
2016/03/27(日) 03:56:05.39ID:???前者より後者の方が速くなると言う考えはあってる。けど、
EXPLAINで調べればすぐ判ることだが、
前者のSQLを実行しても後者の様な手順で処理する。
結局はどちらも一緒。
今時(といってももうかなり前からだけれど)のデータベースはプランナとかオプティマイザが効いて
勝手に効率的な方法で処理してくれる。
0904902
2016/03/27(日) 07:58:40.39ID:???ありがとうございます。
どちらでも同じなのですね。
もし後者のほうが速いのであれば
今書いてるシステムのSQL文をほとんど全て修正しなければならないところでした。
安心しました。
0905NAME IS NULL
2016/03/27(日) 23:13:57.29ID:???合ってないと思う。
一般的には、、
レコード数が少ない時は確かに後者のほうが速いけど、
レコード数が多くなると前者の方が大抵の場合速くなるはず。
PostgreSQLはよーしらんけど、オプティマイザの気持ちになればそうなると思う。
0906NAME IS NULL
2016/03/27(日) 23:21:39.65ID:1TSsmfGU0907NAME IS NULL
2016/03/28(月) 02:01:39.39ID:???0908NAME IS NULL
2016/03/28(月) 06:41:56.10ID:???え? 行数が多くなるほど先にid=4で抽出する後者の方が速いと思うけど。
なんか前提条件でずれてない?
「前者より後者の方が...」と書いたのはSQLに書かれたとおりの順序で処理したらってことで、つまり
先に全部JOINしてからid=4を抜き出すより、
foo.id=4だけ取り出してbarとJOINした方が速い。
というつもりだったのだけれど。
0909NAME IS NULL
2016/03/28(月) 08:34:21.60ID:???JOINするのはかえって遅くなるだろう。
前者は別に、先に「全部」JOINするわけじゃないしな。普通のプランナなら、
駆動表fooをなめてid=4に該当するレコードがあればそれをbarとJOINする。
0910NAME IS NULL
2016/03/28(月) 08:42:55.07ID:W6YzWt9c> 先に抽出してJOINするのはかえって遅くなるだろう。
と
> 駆動表fooをなめてid=4に該当するレコードがあればそれをbarとJOINする。
は同じ事を言っているようだが何が言いたいの？
0911NAME IS NULL
2016/03/28(月) 19:06:57.55ID:???こんな議論するよりは。
0912NAME IS NULL
2016/03/28(月) 20:12:10.42ID:???idやnameにインデックスが無い前提なのもまあ現実的でない気はするけど
0913NAME IS NULL
2016/03/28(月) 21:29:22.18ID:???>foo.id=4に該当するレコードがメモリに収まらないほど多い状況
すまん、やはり前提条件が違うな。foo.idってユニーク(もしくはそれに近い)と考えていた。
そもそもプランナとか無視して、SQLに書かれた順にってつもりだったし。
>>911のいうように結局はEXPLAINで確認した方が早い。
0914NAME IS NULL
2016/03/28(月) 21:35:18.44ID:???0915NAME IS NULL
2016/03/28(月) 21:35:53.39ID:???0916NAME IS NULL
2016/03/29(火) 00:56:34.72ID:???遅いって言われたらよってたかって突っ込むから。
ありがちなのは特別に遅い？ というパタン。
勘違いパタンがほとんど。
0917NAME IS NULL
2016/03/29(火) 09:45:03.60ID:???ヾ'＿＿＿＿＿
|| | |
||o .| |
|| | |
0918NAME IS NULL
2016/03/29(火) 10:47:20.94ID:???> PostgreSQL詳しくないけど、ネステッドループしかないのかよ？
詳しくないなら黙っとけ。
> idやnameにインデックスが無い前提なのもまあ現実的でない気はするけど
こんなアホなこと言わずに済むから。
0919NAME IS NULL
2016/04/01(金) 11:34:36.51ID:???http://www.postgresql.org/about/news/1656/
0920NAME IS NULL
2016/04/10(日) 19:28:28.80ID:???（ホットスタンバイというものかな？）
0921NAME IS NULL
2016/04/11(月) 20:13:44.74ID:???「並列処理」のイメージがよくわからん。
ストリーミングレプリケーション構成で参照分散という意味なら出来ると思う。やったことないけど。
ただ、自働フェールオーバー機構は自分で組まないとダメ。
0922NAME IS NULL
2016/04/12(火) 05:56:30.08ID:???自働フェールオーバー機構？
・・・調べてみます。
並列処理と書いたのは、
１台が故障してももう一台のPostgreSQLが自動的に動作してくれる
という構成をイメージしてます。
お聞きしたい点は以下２つです。
Ｑ１．その構成がWindows版PostgreSQLで安定稼働するのかどうか。
Ｑ２．テーブルを追加したり、列を追加したりするとき、２台の関係を切り離して
各々のDBに変更を適用してから繋ぎ直すのか、それとも２台の関係を維持したまま
片側を変更すれば自動的に２台目にも変更が適用されるのか。
どうなんでしょうか？
0923NAME IS NULL
2016/04/12(火) 10:24:32.14ID:???その意味では「自動切替」くらいに表現したほうが誤解は無いと思うよ。
並列処理だと、多数のクエリ or 1個を共同作業で、複数台で処理することを指す場合もあるから。
A1. 信じるしかない部類だが、（同じマシンにLinuxを入れた場合と比べて）性能は出なくても不安定ではない印象。
A2. テーブル変更系 (DDL) も複製してくれるので繋いだままでよい。ここはPGの優れた点。
0924NAME IS NULL
2016/04/12(火) 10:38:48.27ID:???http://d.hatena.ne.jp/ttshrk/20110421/1303380112
こんな感じ
0925NAME IS NULL
2016/04/12(火) 11:09:22.80ID:???なら はい ですよ。
ストリーミングレプリケーション当りからもう世界が変わっています。
参照クエリなら分散も出来る。
なんの心配もないですよ。
0926NAME IS NULL
2016/04/13(水) 10:35:24.45ID:???レプリケーション構成にするのに背中を押してもらえた感じです。
ところで新たな疑問が・・・
一時テーブル（テンポラリテーブル）を作成しそれを参照して結果を返すような
処理をしているのですが、レプリケーション構成でも大丈夫なのでしょうか？
つまり、一時テーブルも複製されるのか？
という質問になるのかな。
なお、クライアントとDBは非持続的接続ですが、一時テーブル作成する時もそれを参照
するSELECTを発行するときも、同一のDB接続ハンドルを使っています。
分かる方、教えてください。
0927NAME IS NULL
2016/04/13(水) 10:48:02.92ID:???一時テーブルが有効なのは、同一セッション内（あるいは同一トランザクション内）でしかないんだが、
何か勘違いしていないか？
0928NAME IS NULL
2016/04/13(水) 11:24:00.96ID:???同一のDB接続ハンドルなので、同一セッション内 です。
0929NAME IS NULL
2016/04/13(水) 16:36:28.24ID:???0930NAME IS NULL
2016/04/13(水) 17:38:34.65ID:???0931NAME IS NULL
2016/04/13(水) 18:08:31.15ID:???セッションあるいはトランザクションが終了すると、一時テーブルは削除されるのだが
0932NAME IS NULL
2016/04/13(水) 18:22:28.33ID:???0933NAME IS NULL
2016/04/13(水) 18:34:08.31ID:???0934NAME IS NULL
2016/04/13(水) 18:37:13.00ID:???お前>>926か？
お前がレプリケーションに関してわかってないことは、>>926だけじゃない
後から後から疑問がわくのはわかりきってるんだから、まず自分で全体の概要をつかむのが早道
0935NAME IS NULL
2016/04/13(水) 18:50:05.89ID:???0936NAME IS NULL
2016/04/13(水) 19:00:10.61ID:???> つまり、一時テーブルも複製されるのか？
されない
0937NAME IS NULL
2016/04/13(水) 19:44:28.15ID:???一言言うよ お前のようなやつが一番要らないんだよ。出てけばかが。
もちろん926じゃねーよ。
0938NAME IS NULL
2016/04/13(水) 20:59:27.28ID:???0939NAME IS NULL
2016/04/14(木) 10:28:34.75ID:???お前のような奴もいらんわ
0940NAME IS NULL
2016/04/14(木) 11:22:42.00ID:???0941NAME IS NULL
2016/04/14(木) 11:35:23.11ID:???0942NAME IS NULL
2016/04/14(木) 11:42:49.78ID:???何か病気を抱えていないか疑った方がいい。
普通はスルーするし。
0943NAME IS NULL
2016/04/14(木) 11:59:34.67ID:???0944NAME IS NULL
2016/04/14(木) 16:24:07.82ID:???0945NAME IS NULL
2016/04/14(木) 17:02:45.91ID:???0946NAME IS NULL
2016/04/14(木) 17:27:35.00ID:???0947NAME IS NULL
2016/04/14(木) 17:44:06.46ID:???こんなマヌケな質問する奴の気がしれんわ。
もちろん趣味で調べてるだけなんだよな？
0948NAME IS NULL
2016/04/15(金) 13:53:27.34ID:???0949NAME IS NULL
2016/04/15(金) 15:58:08.38ID:???port変えれば2つのPostgreSQLサーバーとして起動できるから、
その間でレプリケーション組める。
0950NAME IS NULL
2016/04/15(金) 16:14:47.03ID:???0951NAME IS NULL
2016/04/20(水) 11:06:32.14ID:???ある text型の列が正しくソートできません。
その列に、COLLATE "C" を付けると正しくソートされます。
何が間違っていたのでしょうか？
0952NAME IS NULL
2016/04/20(水) 11:58:27.80ID:???0953NAME IS NULL
2016/04/20(水) 14:19:46.14ID:???0954NAME IS NULL
2016/04/20(水) 14:55:03.90ID:???0955NAME IS NULL
2016/04/20(水) 15:03:09.79ID:???デフォルトで指定されるencoding, localeが目的に合致しているかどうか判断して
合致してなければパラメータを指定するだけ
0956NAME IS NULL
2016/04/20(水) 15:04:00.97ID:???日本の環境だと実情にあってないのよね
0957NAME IS NULL
2016/04/20(水) 15:06:11.80ID:???0958NAME IS NULL
2016/04/20(水) 15:20:00.48ID:???0959NAME IS NULL
2016/04/20(水) 15:37:39.58ID:???他は結局コード値ソートになる場合が多い
全くバラバラになる環境もあるのか？
0960NAME IS NULL
2016/04/20(水) 16:20:05.71ID:???0961NAME IS NULL
2016/04/20(水) 18:21:23.64ID:???0962NAME IS NULL
2016/04/20(水) 19:20:21.12ID:???正しいソートとは何か、とか哲学的(?)なことは良くわからないですが、
--no-locale の問題かなっていうことはなんとなくわかりました。
つきましては、これから(運用開始後)それに変えるにはDBを停止する必要が有りますか?
365日24時間停止できないです。
また、変えたことによって副作用(?)とかの問題はありますか?
今のところソート以外は問題は無いです。
LIKE演算子(?)とかでも問題は発生していません
0963NAME IS NULL
2016/04/20(水) 19:21:54.60ID:???0964NAME IS NULL
2016/04/20(水) 19:55:13.63ID:???お前は initdb が何をするコマンドなのかを理解するまでそのシステムに触るな
マジで怖いわ
0965NAME IS NULL
2016/04/20(水) 20:01:56.78ID:???バージョンの記載が無いから、バージョンによってはinitdbからやり直し。
以下の好きな方法を選べばいいんじゃないかと。
・クエリを修正する
・カラムごとに照合順序の設定をする
・別途DBを作成して移行する
てか365日24時間停止できないというのなら、むしろDBは停止しても問題ない構成になってないとおかしい。
365日24時間停止できないといいながらHW障害のときは別ですとか？
0966NAME IS NULL
2016/04/20(水) 20:08:14.39ID:???ありがとうございます。
実はEUC-JPで運用していた時は問題なかったです。
ひょっとして--no-locale でinitdbしていたのかもしれませんが。
その後、UTF-8に変更してから問題が表面化しました。
あと、営業上は停止できないけど、障害のことは多分考えてないです。
そのときはどうなるのか誰も考えてないです。
0967NAME IS NULL
2016/04/20(水) 20:09:49.31ID:???特に問題はありません。
0968NAME IS NULL
2016/04/21(木) 13:59:05.71ID:???0969NAME IS NULL
2016/04/21(木) 14:22:04.32ID:???0970NAME IS NULL
2016/04/27(水) 13:10:58.40ID:???「ああ、助かったぁ！」
って経験のある人、いるの？
実際見たことないし逆に複雑さがデメリットになってる気がする
0971NAME IS NULL
2016/04/27(水) 13:13:31.53ID:???0972NAME IS NULL
2016/04/27(水) 14:06:02.70ID:???セキュリティパッチ当てない派？
0973NAME IS NULL
2016/04/27(水) 14:22:28.91ID:???0974NAME IS NULL
2016/04/27(水) 14:44:46.26ID:???0975NAME IS NULL
2016/04/27(水) 15:35:11.93ID:???0976NAME IS NULL
2016/04/27(水) 15:36:05.14ID:???セキュリティパッチって冗長構成なのか？
初めて聞いた
0977NAME IS NULL
2016/04/27(水) 15:38:19.21ID:???俺は
0978NAME IS NULL
2016/04/27(水) 16:33:32.23ID:???24時間運用するなら、冗長構成にしとかないとセキュリティパッチ当てられないだろ
0979NAME IS NULL
2016/04/27(水) 16:34:02.56ID:???じゃ何が問題なんだ？
0980NAME IS NULL
2016/04/27(水) 16:54:31.24ID:???知らんが
0981NAME IS NULL
2016/04/27(水) 17:05:56.95ID:???0982NAME IS NULL
2016/04/27(水) 17:21:16.18ID:???0983NAME IS NULL
2016/04/27(水) 17:32:03.99ID:???0984NAME IS NULL
2016/04/27(水) 17:36:53.95ID:???0985NAME IS NULL
2016/04/27(水) 17:49:16.12ID:???まあルーターの故障により冗長構成がうまく機能しないという自己診断で
自ら落ちたようだが
0986NAME IS NULL
2016/04/27(水) 19:32:58.98ID:???0987NAME IS NULL
2016/04/28(木) 10:56:30.90ID:???セキュリティパッチ当てるのにいちいちDB停止しないといけないの？
0988NAME IS NULL
2016/04/28(木) 11:02:54.38ID:???exe入れ替えだしどうしても止まる
止めずに済むような商用品もあるんだろうが
内部的に多重構成してくれてるんだろう
0989NAME IS NULL
2016/04/28(木) 11:53:24.87ID:???0990NAME IS NULL
2016/04/28(木) 12:09:36.84ID:???ああそうか
PGの更新だと思い込んでた
PGなら実行ファイルの入れ替えだか
OSや他のことならその限りではない
0991NAME IS NULL
2016/04/28(木) 12:17:08.95ID:???やってみりゃなんのこたない。
0992NAME IS NULL
2016/04/28(木) 12:53:11.78ID:???それこそ、自宅鯖かよ？ってはなしだわなwww
0993NAME IS NULL
2016/04/28(木) 13:47:44.57ID:???プログラムの更新。
普通は、更新するとdaemonあるいはserviceの再起動が必要。
0994NAME IS NULL
2016/05/03(火) 11:36:44.88ID:???ポストグレスQL
QLなんだぁーーー
0995NAME IS NULL
2016/05/03(火) 12:31:36.06ID:???引っ込んでろ
0996NAME IS NULL
2016/05/03(火) 15:28:11.65ID:???いい大人になれませんよ。
0997NAME IS NULL
2016/05/03(火) 15:43:21.81ID:???そんな怒んないでよ
次スレ立てたから許して
PostgreSQL Part.11
http://echo.2ch.net/test/read.cgi/db/1462257753/
0998NAME IS NULL
2016/05/03(火) 15:44:54.58ID:???まあいいやｗ
0999NAME IS NULL
2016/05/03(火) 15:44:58.18ID:???1000NAME IS NULL
2016/05/03(火) 15:48:03.94ID:???10011001
Over 1000Threadもう書けないので、新しいスレッドを立ててくださいです。。。
life time: 797日 12時間 12分 50秒
10021002
Over 1000Thread運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ ２ちゃんねる専用ブラウザからの広告除去
★ ２ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
http://premium.2ch.net/
http://pink-chan-store.myshopify.com/
レス数が1000を超えています。これ以上書き込みはできません。