大量のデータを高速に投入するには — Let's Postgres
FORCIA, Inc. 板垣 貴裕 PostgreSQL に大量のデータを高速に取り込む方法を紹介します。 COPY という専用のコマンドを使うと INSERT よりもずっと高速です。 また、COPY を使う際にひと工夫すると、さらに速くなります。 高速にデータをロードするコマンド INSERT の代わりに COPY FROM を使う PostgreSQL には COPY FROM という大量データ取り込み専用のコマンドがあります。 COPY コマンドは外部からタブ区切り (.tsv) やカンマ区切り (.csv) のファイルを読み込める上に、INSERT よりもずっと高速です。 同様に、pg_dump コマンドも -d や --inserts オプションを付けると INSERT を並べたダンプファイルを作ってしまいます。 オプションを付けないデフォルトでは高速な COPY 形式なので、
PostgreSQLの設定 チューニング — そこはかとなく書くよん。 ドキュメント
PostgreSQLの設定 チューニング¶ PostgreSQL when it is not your job - Christophe Pettus 経由で DjangoCon Europe 2012 で発表された このスライド を知ったので、 メモ代わりに残してみる。件のblogは抜粋なので、ここでは可能な限り全部載 せます。 最初に¶ 気をつける設定はこれだけ。 ログ メモリ チェックポイント プランナー ログ¶ ログに対して寛容になること。システムへの影響は少ない。 ログは性能問題を解決するための一番いい情報。 どこにログを出す？¶ syslog: すでにsyslogを使うシステムを構築してるならこれがいいでしょう 標準形式のファイル: 標準形式のファイルを使うツールをすでに使っていればこれ。 そうでなければ CSVフォーマット あとの設定はこれ。 log_destination
PostgreSQL when it is not your job - Christophe Pettus - Reinout van Rees
You are here: Home → weblog → 2012 → 06 → 04 → PostgreSQL when it is not your job - Christophe Pettus PostgreSQL when it is not your job - Christophe Pettus¶ Tags: django, djangocon (Note beforehand: I didn’t get everything. You really also have to look at his slides for the details. Thanks Christophe for posting the slides right afterwards!) Update: this article was mentioned on ycombinator. Ther
はてなブログ | 無料ブログを作成しよう
思いは言葉に。 はてなブログは、あなたの思いや考えを残したり、 さまざまな人が綴った多様な価値観に触れたりできる場所です。
PostgreSQL導入に向けての取り組み ～大規模システムへの適用を目指して～ | Let's POSTGRES
NTTコムウェア株式会社 基盤技術本部 山内 孝彦 吉田 敏和 はじめに 2009 年 11 月に JPUG 10 周年記念として開催された「PostgreSQL Conference 2009 Japan」において、「大規模システムへの PostgreSQL の適用」に向けた NTTコムウェア株式会社（以下 NTTコムウェア）の取り組みについて発表させて頂きました。 今回は当日説明させて頂いた内容に加えて、そこに至った背景なども合わせてご紹介いたします。 1. NTTコムウェアの紹介 NTTコムウェアは 1985 年に日本電信電話株式会社内に発足した中央ソフトウェアセンタが起点となり、 1997 年に NTTコミュニケーションウェア株式会社として設立され、 2000 年に NTTコムウェア株式会社に社名を変更し、現在に至ります。 設立当初は NTTグループ内の情報通信システムのソフト開発
PostgreSQL 8.3 以降からの postgresql.conf を、サーバースペックによるデフォルト値を設定し、パフォーマンスを調整する
DoRuby! (ドルビー!) は現場のエンジニアによる、主にRubyなどの技術に関する様々な実践ノウハウを集めた技術情報サイトです。 こんにちは、O2 です。今回は、postgresql の設定ファイル（postgresql.conf） に関しての、私が最近設定しているデフォルト値を公開しようと思います。 実際、インストール直後の設定では、「ロースペックのマシン環境でも動作する」設定の為最近のサーバースペックにあった、デフォルト値を記述してみようと思います。 とは言っても、私が扱っている最近のサーバーのメモリは、8GB、16GB、32GB で、さらにPostgreSQL 8.3以降を使用しているので、PostgreSQL 8.3以降での、メモリ3パターンでのデフォルト値を紹介します。 注意．あくまでも、私が割り出したデフォルト値ですので、どのように使用するかによってチューニングは必要にな
LinuxでPostgreSQLパフォーマンス向上
たとえばDebian packageをそのままもってくるとi486用のコードで 実行されることになる。自分の使っているマシン上でコンパイルすると CPU別に最適化してくれるので、数％から１０数％程度の高速化が期待 できる。 IDEのハードディスクを接続していてDMAが使えない状態だと極端に遅くなるの は当然である。が、しかし、たまに「LinuxのHDDアクセスは遅い」と騒いでい るのを見かけるので、一応、書いておく。 $ sudo hdparm -mcd /dev/hda /dev/hda: multcount = 16 (on) I/O support = 1 (32-bit) using_dma = 1 (on) using_dmaがonになっていれば良い。なっていなければ $ sudo hdparm -d 1 -c 1 -m 16 /dev/hda /dev/hda: settin
Tuning Your PostgreSQL Server - PostgreSQL wiki
by Greg Smith, Robert Treat, and Christopher Browne PostgreSQL ships with a basic configuration tuned for wide compatibility rather than performance. Odds are good the default parameters are very undersized for your system. Rather than get dragged into the details of everything you should eventually know (which you can find if you want it at the GUC Three Hour Tour), here we're going to sprint thr
pg_bulkload: プロジェクト ホームページ
はじめに pg_bulkloadは一定の制約条件の下で大量のデータを高速にロードするためのプログラムです。 大量のデータを投入するような状況では、細かなチェックは省いてでもいいからとにかく 高速にデータをロードしたいという場面があります。たとえば、あるデータベースに格納 されている情報を別のデータベースへ移送するような状況や、これから投入しようとする データの整合性がすでに別のツールで保証されているような状況がこれにあたります。 このような状況を想定して pg_bulkload は開発されました。 したがって、整合性を確認できていないデータのロードに対して、 pg_bulkload の使用 は適していません。この場合にはPostgreSQLがデータロードのためにもともと用意して いる COPY コマンドの利用をお勧めします。 注意点、使用方法を十分に理解した上で、pg_bulkload を
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
PostgreSQLを本当に高速化したい人のための10のポイント | 独り言v6
空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ -空気を読まずにPostgreSQLのを高速化する10のポイント - 象と戯れ - postgresqlグループ.の元エントリを読んで思うところがあったのだが、 PostgreSQLを高速化する16のポイント だからそんなせまっくるしいところでトンチンカンにdisる暇あるんだったら自分のブログでお好みの議論を書くかさもなきゃ/dev/nullにでも吐けとやんわりと言ってるんだよハゲ。 というわけでｗ。 だよねｗ。 まあ正直、上記元ネタのほうには色々突っ込みどころ満載なのだが、それは置いておくとしてL.starなりの高速化ポイントを一度書いておかないと、と思ったので記す。ただ、L.starはもうPostgreSQL界隈から離れて久しいので、必ずしも最新の内容を網羅していないことに注意されたし。また、出来るだけPos
はてなグループの終了日を2020年1月31日(金)に決定しました - はてなの告知
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
[ThinkIT] 第1回：postgresql.confによるチューニング
PostgreSQLに限らず、データベースソフトは大量のデータを扱うので、場合によっては処理にかなり時間がかかることもあります。そのため、できるだけ処理時間を短縮し、処理効率を向上する「チューニング」という技術が重視されています。 Webシステムのように数多くのリクエストを同時こなさなければならないシステムでは、個々の問い合わせの処理時間は数百ミリ秒と短くても、全体の処理時間が膨大になることがあります。このようなシステムでは、1つ1つの処理時間をできるだけ短くすることが重要です。 また、「バッチ処理」においても処理時間の短縮は重要です。バッチ処理とは、ユーザーと対話的に行われる処理ではなく、自動的に実行される処理です（多くの場合、人手を介することはありません）。たとえば1日のデータを夜間にまとめる「日次処理」などがこれに該当します。日時処理が決められた時間内に終わらなければ、処理自体が無意
PostgreSQLのトラブルシュートとチューニング — Let's Postgres
NTT オープンソースソフトウェアセンタ 笠原 辰仁 この記事は、gihyo.jp & Let's Postgres 連動企画「今こそ！PostgreSQL」の第6回記事です。第6回目は、PostgreSQLのエラーメッセージや内部情報を見て、発生している問題の特定とその対策となるチューニングを紹介します。なお、トラブルの発生・予兆を適切に捕捉するためにも、ログの設定や稼動統計情報の監視をしておきましょう。 エラーメッセージについて トラブルと対策の前にエラーメッセージのレベルについて説明しておきます。PostgreSQLは複数のエラーレベルを影響範囲や深刻度によって使い分けています。エラーレベルそれぞれの解釈の仕方を下記の表にまとめてみました。 データベース管理者は、深刻な状況である PANIC と、性能情報を含む LOG レベルのメッセージに注意しましょう。一方、アプリケーション開発者
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://thebuild.com/presentations/not-your-job.pdf
第11回勉強会 — NPO法人 日本PostgreSQLユーザ会
http://neta.ywcafe.net/000800.html
ProGains Foundry | Great Supplements, Great Results
ProGains Foundry | Great Supplements, Great Results