icon

デイリー おさ 紙が更新されました! bit.ly/k5AYji ▸ 本日トップニュースを提供してくれたみなさん:

Web site image
Build your digital presence with Paper.li
icon

"ナウシカ 「汚れているのは土なんです…」 hatsukari.2ch.net/test/read.cgi/… 246 名前:名無しさん@涙目です。(北海道)[]..." tumblr.com/xpu4i7yt65

Web site image
ナウシカ 「汚れているのは土なんです…」http://hatsukari.2ch.net/test/read.cgi/news/1301183084/246 名前:名無しさん@涙目です。(北海道)[] 投稿日:2011/03/27(日) 10:17:36.78 ID:sQJaaguFO [7/9]地球の長い午後から発想を得たとはいえ菌類の森を馬鹿デカイ虫がはいずり回っているという発想がすげえよな254 名前:名無しさん@涙目です。(東京都)[sage] 投稿日:2011/03/27(日) 10:23:50.40 ID:KjhF6nq3P [4/6]»246最近の実験データでは現実世界でも腐海の植物のように核物質を分解してしまう連中がいることが判明してるわずか20年で1万年必要だったプルトニウムの半分がどこかに行った理由を調べた時ロシアは驚愕したおぞましい量の放射性物質を食べて別の物質に変換する細菌と同じ効果を持つ細胞を持った植物がウクライナに根付いてたんだ彼らは、恐ろしい量の放射線を浴びながらも死にそうになりながら生きて放射性物質を分解し別の物質に変換しつつ、大量の放射線を地中から吸収しては枯れていくその繰り返しが20年行われた結果「半減期1万年」だったはずのプルトニウムの約半分が何時の間にか「半減期30年」といわれるセシウムや鉛に変換されていたたった20年で予想を上回る速さで土壌が改善されている背景には適応力によって適応した植物の力があっただが、それだけじゃないんじゃないかと、「あの地域に生きている昆虫は?」って話も出てるあんな悲惨な地域でありながら、植物が育って花をつけるということはその手伝いを担う昆虫にも対放射線能力か、同じような力があるんじゃないかとま、そんな話を聞くとナウシカを想像しちまうな
icon

@TERRAZI 契約解除→住居侵入罪→逮捕→懲役の流れ?

icon

イーモバ解約届け記入done

icon

思ったより電車が発車しない

icon

モバツイ、速く入力すると反映されないな。って、なんだそれ。

icon

WiiUって都市伝説じゃなかったんや。

icon

宝箱は空だった

icon

あの距離を13分で歩けというのかgoogleさんは。

icon

傘持ってない

icon

虹が出てる。

icon

osaponとごはんたべたい人が1人います。あなたとごはんたべたい人数→ gohantabeyo.com/nani/1?prefill…

icon

インタビューズのお知らせが、何も表示されないのに、未読1件になってしまってる。

icon

作業テーブルつくんなってのは分かるんだが、他に解決方法が思いつかない。

icon

PostgreSQLって、contribの中身をピックアップしてサーバと一緒にビルドできないんかな。make worldで全部はビルド出来るみたいだが、全部は要らないんだ。

icon

@maname かわいそう・・・

icon

"事故発生当時、スイッチャー担当の技術者は「オレ何にも触ってないよ」などと発言したそうである。筆者にはそれが腹立たしい。自分以外の人間の操作ミスによるOA事故のリスクマネージメントを、技術者が負っていないからで..."... tumblr.com/xpu4ildvr1

Web site image
事故発生当時、スイッチャー担当の技術者は「オレ何にも触ってないよ」などと発言したそうである。筆者にはそれが腹立たしい。自分以外の人間の操作ミスによるOA事故のリスクマネージメントを、技術者が負っていないからである。そしてそこの「予定外のテロップがOAに出てしまった」という事故を引き起こした責任は、DSKをいつまでもONにしたままで放置した技術者にある。
icon

id,col1なテーブルAとid,col2なBをFULL OUTER JOINしてid,col1,col2にしようと思ってる(idは完全一致しないのでNULLのcolは0にするCASE文を書いてる)んだけど、処理時間が長すぎる。id,col_type,colにした方がいいのかな。

icon

インデックススキャンかかってるのに(cost=0.00..35135220.84 rows=62620333 width=16)とか、もう助けて。

icon

analyze掛かってないんじゃ無いよ、実際にこんだけの件数があるんだわ。しかも他に6テーブル。

icon

@turugina 最大6千万件と最大6千万件をJOINして、最大6千万件にしようと思ってるんですが、JOIN前から爆発しています。あれ、OUTER JOINてキー指定しても全件結合でしたっけ。ぐぬぬ。

icon

JOINは毎回図解を見ないと理解できない。

icon

ていうか、もう設計を見直さないといけない時期に来た気がする。

icon

SQL構文は大文字で書く派(カラムとテーブル名は小文字で書く分派)

icon

多段JOINがアレっぽいなー。

icon

うーん、実行計画がアホだなぁ。

icon

マージする順番が逆だろっていう。

icon

うーん、クリーンアップ処理もバッチで一括処理にしないで、一件ずつ処理した方が良いのかなぁ。でも何らかのトラブルで集計済みテーブルのカウントがずれたら修復効かなくなるし、結局全部数え直さないといけないしなぁ。

icon

パーティショニングで分割してるテーブルの実行計画はもうちょっと考えて欲しい。ヒントとか指定できたら良いのに。