PostgreSQL Part.11©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
PostgreSQL 9.6 beta1
http://www.postgresql.org/about/news/1668/
9.5から9.1のマイナーバージョンアップも。 マイナーバージョンアップではなく
累積バグ修正と呼べといつも思う DBバージョン上げたら
insert into a select * from a_tmp where code = 1
で
列"b_flg"は型booleanですが、式は型textでした
ってエラー出るようになったんだけど、
CREATE CASTで対処するのが正しい道？ >>9
そこで動かなくなるのってかなり古かったんじゃないか？
a_tmp にある b_flg に相当する列の型を boolean に変更すべきだろう。
CREATE (TEMP?) TABLE a_tmp (LIKE a) すればミスを避けられる。 エスパーじゃないとわかんないのかｗ
説明すると
table a
code integer
b_flg boolean
table a_tmpも同じ構成のテーブル
で、booleanのフィールドがTRUEとか返すんだけど、それが
文字列だと思われてエラーになるみたい
# 8.4くらいから？ >>11
もちろんa_tmpの b_flgの型はbooleanです。 って自分でテーブル作って同じの試したらうまくいく・・・・
select b_flg from a_tmp
で
TRUEが帰ってくる時と
tが帰ってくる（こっちでエラーになる）のあるんだけど、何違うんだろ・・・ 「boolean型」なのか「text型にbooleanっぽい文字列が入ってる」のかをきちんと確認したほうが良い。
特にSELECT INTOでテーブルを作るような場合だと型指定が曖昧な場合がある。 >>9
> DBバージョン上げたら
何から何に上げたのか
> insert into a select * from a_tmp where code = 1
どこでこれを実行しているのか
> table a_tmpも同じ構成のテーブル
本当か？
> で、booleanのフィールドがTRUEとか返すんだけど
何で実行するとそうなるのか
> 文字列だと思われて
思う主体は何か？ > って自分でテーブル作って同じの試したらうまくいく
うまくいく環境と、うまくいかない環境の差異は何か >>9
> CREATE CASTで対処するのが正しい道？
なわきゃない 質問: shared_bufferを16GBに設定しているのに、実際にはそれ以下しか使用されてないっぽいんだが、どういうことでしょうか。
sahred_bufferの値が16GBであることを確認
$ grep shared_buffers /etc/postgresql/9.3/main/postgresql.conf
shared_buffers = 16GB # min 128kB
メモリ使用量を確認 (ファイルキャッシュを除くと9.781GBしか使われてない)
$ free -m
total used free shared buffers cached
Mem: 64384 64065 319 0 0 54284
-/+ buffers/cache: 9781 54603
Swap: 65487 120 65367
なおデータサイズは40GB程度。最大のテーブルが20GBくらいあって、それを全件検索してもメモリ使用量が増えない。
そのせいで性能が頭打ちになっている。だれかヒントおねがい。 >>21
SeqScan時は一定量のメモリでやり繰りする機能が入っているから全メモリは使わない。
強制的に共有バッファに乗せたいなら pg_prewarm を試すといい。
そして、「そのせいで性能が頭打ち」は誤解だったと気付くだろう。 >>22
ありがとうございます。こんな便利なモジュールがあるんですね。
とはいえインストールするのはDBAの許可が下りなさそうなので困りました。
>>23
ありがとうございます。pg_prewarmのmanualページを読むと、
「プレウォームはキャッシュが主に空のとき、一般的には起動時にもっとも有用です。」
とありました。起動時以外は効果は薄いんでしょうか。困りました。
> そして、「そのせいで性能が頭打ち」は誤解だったと気付くだろう。
そうなんでしょうか。今のところ、HDDから最初に読み込むときに時間がかかるのが問題であり、2回目以降は高速なのでSQLは問題ないかなと思ってます。
たとえば select * from users where id = :user_id のようなSQLがあったら、
2回目以降はメモリキャッシュに載っているので数msですが、ユーザごとの最初の
アクセスではHDDから読み込むので、2秒〜3秒かかってしまうのが問題です。
それで、shared_bufferを16GB設定しているのに実メモリは9GBしか使っていない
（ファイルキャッシュを除く）のを改善すれば解決できると思っているんですが、
甘いでしょうか。 >>24
ああ、全件検索が遅いのが問題なんじゃなくて、
全件検索ではウォームアップができないのが問題だったのか。
それなら pg_prewarm が適するだろうね。
テーブルだけでなくインデックスも prewarm が必要か確認して欲しい。
「起動時以外は効果は薄い」とは「あくまで準備体操」の意味。
全ユーザが一通りアクセスした後のメモリ状態になるまでの時間を早めているだけだからね。 >>24
> たとえば select * from users where id = :user_id のようなSQLがあったら、
> 2回目以降はメモリキャッシュに載っているので数msですが、ユーザごとの最初の
> アクセスではHDDから読み込むので、2秒〜3秒かかってしまうのが問題です。
そのたとえが本当に適切なたとえだとしたら、遅い原因はキャッシュにのってないから
じゃなくて、インデックスがないからだな。 さすがにそれは考えにくいから例えが適切じゃなかったんだろうなぁ。 すみません、教えてください。
Windows7/8/10などのクライアントOSにPostgreSQL本体をインストールして、他のPCからそのＤＢに
アプリケーションで読み書きした場合、Windowsのライセンス違反になるのでしょうか？
ttp://itpro.nikkeibp.co.jp/article/COLUMN/20060811/245694/?rt=nocnt
↑のような制限にかかってしまうのでしょうか？
もしライセンス違反なら、PowerGresのような製品でWindows7/8/10で動作すると書いてあるん
ですが、これはスタンドアロン限定ということですか？ >>28
ここで聞くより、PowerGres販売元にメールで聞いた方が良いと思う。 >>28
> アプリケーションで読み書きした場合、Windowsのライセンス違反になるのでしょうか？
なる。
というのが本当かどうかを知りたければ、まずこれを読め。
http://www.haruru29.net/blog/windows-share-files-20-devices/
納得できなければ、MSに聞くのが手っ取り早い。
> もしライセンス違反なら、PowerGresのような製品でWindows7/8/10で動作すると書いてあるん
> ですが、これはスタンドアロン限定ということですか？
じゃないの？ 通信したらいかんの？
windows上のブラウザからデータもらうWebサーバーはみんなライセンス違反？ IISなら限定的に公開してもいいという話もあるな
ただし、同時接続数10までというのは、同時に10台のクライアントからと言う意味ではなく、
connectionの数という話もある
普通のブラウザでアクセスすると、同時に5本くらいアクセスに行くから、台数でいうと2台までとか
そんな制限になってるらしい
まあ、Microsoftに質問するのが確実だろうが
（ただ、Web情報によれば、サーバ用途は駄目と言われるらしいが） すごく古い情報だが、
http://www.atmarkit.co.jp/fwin2k/win2ktips/207rest_iis_pro/rest_iis_pro.html
> Webサーバの機能制限
> TCPでの同時接続数は最大10個まで
> TCPレベルでの同時接続数が最大で10個までに制限される。1人のユーザーが多数のTCP接続を開始している場合には、それだけで10個のTCP接続がいっぱいになってしまう可能性がある
これが正しい情報で、なおかつ今でも有効だとすると、事実上Webサーバとしては機能しないだろう ちなみに、MS謹製のサーバ機能以外のアプリは、問い合わせると軒並み駄目だと言われる気がする
（個人の想像です） ですよねぇ。ソース持ってきてメイク、インストールでそのまんま使えるのが
気持ちいい。ぼろいＰＣでもまぁ動く。社員ＤＢぐらいならそんなもんで十分。 電話でpowergressに聞くと、クライアントOSにポスグレをインストールして他の端末からアクセスしても問題ないはず、そんな問い合わせはないとのこと。メールじゃないから正式回答かは分からないが。
しかしマイクロソフトによると、それはNG。ポスグレがインストールされてる端末のアプリケーション(ポスグレ本体）を介して結果を返しているので、サーバにしか許されない操作をしていることになるらしい。
ベンダーによっては、本来NGの使い方を製品ページで提案してるが、知らないか、都合よく解釈してるか、どっちかなんだろうな。 >>41
> 電話でpowergressに聞くと、クライアントOSにポスグレをインストールして他の端末からアクセスしても問題ないはず、そんな問い合わせはないとのこと。メールじゃないから正式回答かは分からないが。
なんと質問したかによるな。
ちゃんとWindowsのライセンス的に問題はないか聞いたか？ サーバ用途なのにWindows Serverを使わないような貧乏人にはLinux (サポート無し) がお似合い シュリンクラップ契約は有効かっつー話はあるけどな。 真面目な人ほど、コンプライアンスに厳しい会社ほど
従います。当たり前ですけど。 >>47
共有するブックを置くファイルサーバーが Windows Server ならなんの問題もない
つか、コンテンツの問題じゃないし unique制約のindexをdescで作れますか PostgreSQLはストレージがHDDじゃなくてSSDでも装置の特性に合ったバッチリ最適なデータの出し入れをしてくれますか？ してくれません
プランコストの調整くらいはできるが
基本的にはOSに丸投げ 他のRDMSではSSD用に処理が分かれているのだろうか ストレージが比較的高速なサーバー機だとデフォルトのrandom_page_costが
全然合わないから調整必須、ってのは昔からだな。 ■質問内容
検索結果の続きを取得するSQLを教えてください。
■詳細
データベースを検索し、100件ずつ取得しようとしています。
検索結果は100件ずつ取得するため、検索結果が100件以上ある場合は、
続きとして101件目から取得することになります。
通常はOFFSET句を使用して続きを取得しますが、更新の多いデータベースのため、
レコード数が増減する可能性があり、OFFSETで特定の数スキップすると問題が発生します。
例えば、続きの100件を取得する際、スキップする最初の100件の中に新たなレコードが1件増えると、
最初の100件取得した際の100件目のレコードと、続きの101件目のレコードは同じものになります。
WHERE句で解決を試みようとも思いましたが、ユニークな値でORDER BYをかけているわけではないため、不可能と判断しました。
ORDER BYで対象としているカラムの結果は同じ値のものも含まれており、
その同じ値の続く途中で件数によって区切られた場合、そのカラムをWHEREの対象にはできません。
助けてください。 ソートキーは当然あるわけだから、「前回の最後のソートキーより大きな100件」を取得すればいいんでない？ >>62
すいません、ソートキーというのはORDER BYで指定するカラムですよね。
そのカラムの値がユニークではないので、その値で判定できないんです。
このようなイメージです。
〜 ORDER BY score;
score
--------
2500
2800
3000
3000
3000
3400
例えばこれで3件ずつ取得するためにLIMIT 3を付けた場合、3000のスコアの途中まで取得されるので、
WHERE > 3000というような形で指定できないのです。 テンポラリテーブル作って検索結果突っ込んでおくとか
主キーだけでも >>61
続きを取得している間はトランザクションは開きっぱなしなのか？
更新されても結果が変化しないのが条件なら
開きっぱなし or 全行を一時保管しておく必須がある
トランザクションを切るなら並行する更新結果も見えてしまうが
更新によって主キーとソートキーが変わらないならば
「欲しいソートキー + 主キー」を条件にすればいい
ORDER BY score, pkey WHERE score >= 前回のscore AND pkey > 前回のpkey どうしてPostgreSQLはMySQLに勝てたのか >>63
score が 3000 であるレコード同士の順番をどうにかして決めておかないとだめだよ。
> 例えば、続きの100件を取得する際、スキップする最初の100件の中に新たなレコードが1件増えると、
> 最初の100件取得した際の100件目のレコードと、続きの101件目のレコードは同じものになります。
これを嫌うということは、最新のデータが表示されない可能性があるけれど、それはそれでいいってことかな >>61
> 最初の100件取得した際の100件目のレコードと、続きの101件目のレコードは同じものになります。
逆にそっちの方がいいかもよ。
仮に、scoreの降順でデータを取得するとする。
最初の検索時は350件あって、データの変更がなければ4ページ。
最初は1位5000点)〜100位(4000点）が表示される。
で、その表示中に、4001〜4999点に10人追加されたとする。
その結果、旧91〜100が101〜110位になる。
そのとき、「次」を見たときどうなってるのが良いか？
・旧101〜200位が表示される
・新101〜200位が表示される
今は、こうあるべきだと思っている。
> ・旧101〜200位が表示される
考えて欲しいのは、そこで「前」を見たらどうなっているべきか。
また、新たに追加された10人はいつどのようにすれば見られるのか。 直近のコメントが今日だったから、最近の話題かと勘違いしたわ >>70
実際に勝ってるかどうかは知らないけど、もし勝つとしたら商用無料のせいだろ MySQLと比べるなら、機能的に圧勝してるから比べ物にならないでしょ
PostgreSQLが勝ったというよりは、MySQLが選択肢に入ってなかっただけ
普段からPostgreSQLを使ってるとこは、わざわざMySQLを習得するコストがもったいないから
MySQLをさける傾向がある やってる人はやってるんだろうし、ご勝手にって感じかな。
もう気にかけることも無くなったね。 比べるなら相手はMariaじゃないの？
もしくはローエンドOracleか レンタルサーバで使える所少なかったり
CMSとかで対応してないとかあるからなー
そういう場面ではMySQL選ばざるを得ない え？
PostgreSQLって流行ってるの？
もう廃れてきているのかと思った
どこの記事見ても、MySQLとかMariaDBとかばっかりだもんな postgresql はC
MySQL は C++ いわゆるWeb系はMySQL系
基幹業務にOracleを使う金がないとこはPostgreSQL
ベンチャー企業が中小相手にシステム構築するときに使う
MySQL系の記事が多いのは最近やっと使えるようになってきたからだよ
AWSの影響もあるだろうしな
言語に例えるんだったらPostgreSQLはVBやPHPで
MySQLはJavascriptのイメージだな VBやPHPに例えられても嬉しくないなぁ
レンタルサーバで使えない問題は Heroku Postgres で多少はマシになったか ■ このスレッドは過去ログ倉庫に格納されています
