タグ

postgresqlとdbに関するhide98のブックマーク (12)

  • SQLエスケープにおける「\」の取り扱い

    補足 この記事は旧徳丸浩の日記からの転載です。元URL、アーカイブはてなブックマーク1、はてなブックマーク2。 備忘のため転載いたしますが、この記事は2008年6月2日に公開されたもので、当時の徳丸の考えを示すものを、基的に内容を変更せずにそのまま転載するものです。 補足終わり 昨日のエントリ(徳丸浩の日記 - そろそろSQLエスケープに関して一言いっとくか - SQLのエスケープ再考)は思いがけず多くの方に読んでいただいた。ありがとうございます。その中で高木浩光氏からブクマコメントを頂戴した。 \がescape用文字のDBで\のescapeが必須になる理由が明確に書かれてない。\'が与えられたとき'だけescapeすると…。自作escapeは危うい。「安全な…作り方」3版で追加の「3.失敗例」ではDBで用意されたescape機能しか推奨していない このうち、まず「\」のエスケープが必

    hide98
    hide98 2010/04/23
    \と'のエスケープについて。ライブラリによってはエスケープ関数が不完全な場合があるので、使用する前に必ずチェックを行うこと。
  • [PostgreSQLウォッチ]第31回 ついにPostgreSQL 8.2ベータ・テスト開始!

    2006年9月21日,待望のPostgreSQL 8.2のベータ版がリリースされ,PostgreSQL8.2の全容が明らかとなった。全体的にはそれほど目だった新機能はないが,細かな改善や,性能向上がなされているようだ。 連載でも25回と30回で8.2の新機能や改良点を取り上げてきたが,それを簡単に復習してみよう。 25回では,CE(Constraint Exclususion)という,継承を使ったテーブルパーティショニング機能の改良,pg_freespacemapの追加を紹介した。また,ソート処理とディスク上のビットマップを使ったVACUMMの高速化への試みについても紹介した。残念ながらVACUUMの高速化は盛り込まれなかったが,ソート処理の高速化は8.2に取り込まれた。 30回では,GINという新しいインデックスタイプの追加,COPYやINSERTの改良について紹介した。 稿ではこれ

    [PostgreSQLウォッチ]第31回 ついにPostgreSQL 8.2ベータ・テスト開始!
    hide98
    hide98 2010/03/12
    FILLFACTORを設定する方法
  • 北京市网信办推进自媒体账号专项治理关闭11万个 该楼共召主会开业议4次-武冈新擞蔬菜行情网

    最新文章 2018-12-26 20:02▪ 上思一KTV安全出口数量不足被消防部门依法查封 2018-12-26 20:02▪ 乌向俄放狠话:捍卫刻赤海峡“主权”是我们的责任 2018-12-26 20:02▪ 中餐的魅力有多大?看这些外国人的痴迷程度就知道 2018-12-26 20:02▪ 大冶发生一起3人死亡的冒顶事故公司所属矿山连续7年发生... 2018-12-26 20:02▪ 印度油罐车与客车相撞至少11人死亡 2018-12-26 20:02▪ 视频|两江新区邢家桥社区旁天然气管道泄漏消防队员已成功... 2018-12-26 20:02▪ 日农相拟就重启商业捕鲸寻求国际社会理解 2018-12-26 20:02▪ 上海到青岛高铁建设又进一步!青盐铁路12月26日开通 2018-12-26 20:02▪ “深圳虐童事件”女童身体指标正常克服心理阴影或还需时间 2018-

  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • PostgreSQLのチューニング [データベース] All About

    PostgreSQLのチューニング PostgreSQLは最適なパフォーマンスが出るように自動的に調整されるため、特別なチューニングテクニックは必須ではありませんが、最大限にパフォーマンスを引き出したい場合にはpostgresql.confで指定している値を調整することによりチューニングが可能です。また、PostgreSQLのパフォーマンス向上のためには定期的にVACUUMコマンドを実行することをお奨めします。 ■VACUUMコマンドを実行する VACUUMコマンドはPostgreSQLデータベースの掃除と解析をおこなうコマンドです。 定期的にVACUUMコマンドを実行するとデータベースの問い合わせのパフォーマンスが向上します。 VACUUMコマンドによる処理はテーブルが大きい場合は時間がかかりますので、あまりアクセスのない時間帯におこなうとよいでしょう。 ●VACUUMコマンドの文法 v

    PostgreSQLのチューニング [データベース] All About
  • はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知

    はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

    はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
  • PostgreSQLを本当に高速化したい人のための10のポイント | 独り言v6

    空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ -空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ - postgresqlグループ.の元エントリを読んで思うところがあったのだが、 PostgreSQLを高速化する16のポイント だからそんなせまっくるしいところでトンチンカンにdisる暇あるんだったら自分のブログでお好みの議論を書くかさもなきゃ/dev/nullにでも吐けとやんわりと言ってるんだよハゲ。 というわけでw。 だよねw。 まあ正直、上記元ネタのほうには色々突っ込みどころ満載なのだが、それは置いておくとしてL.starなりの高速化ポイントを一度書いておかないと、と思ったので記す。ただ、L.starはもうPostgreSQL界隈から離れて久しいので、必ずしも最新の内容を網羅していないことに注意されたし。また、出来るだけPos

  • HOTの効果 (1) — Let's Postgres

    現在 (2009年1月) の最新版であるPostgreSQL8.3では、「HOT」と呼ばれる機能が追加されています。この「HOT」により、PostgreSQLの更新処理性能が劇的に向上し、ガベージ発生量が大幅に減少しました。シリーズでは3回に分けて、この「HOT」の効果や仕組み、そして上手な使い方を詳しく解説していきたいと思います。

  • Ywcafe.net

    Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Free Credit Report music videos Migraine Pain Relief Best Mortgage Rates Credit Card Application Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy

  • PostgreSQLを遅くしている犯人はどこだ?

    出力内容を追いかけろ 実際に実行してみてどれだけの時間がかかったかは「actual time=」で表示される数値を追いかけることで確認可能です。例えば、前ページのリストの1行目に出力されている「actual time」だけを取り出すと、次のようになります。 ↓最初の1件目を取得するまでにかかった時間 (actual time=9006.586..9011.968 rows=16842 loops=1) ↑最終的に結果行全体を取得するのにかかった時間 特に、右側の数値である「最終的に結果行全体を取得するのにかかった時間」では、そのSQLの処理開始からの累積時間で表示されます。このため、当該行の処理が完了するまでにどれだけの時間がかかったかを確認できます。 これを基に、SQLの中でどの処理に最も時間がかかっていたのかを確認していきましょう。 Total runtimeが9022.840msであ

    PostgreSQLを遅くしている犯人はどこだ?
  • SQLチューニング(2) ~ 実行コスト(EXPLAIN / EXPLAIN ANALYZE) — NPO法人 日本PostgreSQLユーザ会

    by 柴田 淳 — posted at 2005-10-26 23:48 last modified 2006-12-04 12:41 アプリケーションも何も無いのに、単に「デキの悪いSQLを作って、それをチューニングする」というのは非常に難しい。。 というわけで、とりあえず適当なサンプルデータを取ってくることにしました。ちょうど、IPAのOSS推進フォーラムでOSDLのDBT-1というベンチマークを浸かってPostgreSQLの評価をするとかの資料があったので、これをちょいと利用させてもらって、DBT-1のデータを作成することにしました。 がさごそ。がさごそ。 というわけで、ちょっと手間がかかったのですが、テーブル10コから構成されるサンプルデータベースが作成されました。もちろんサンプルデータもあります。 testdb=# \d List of relations Schema |

  • 1