PostgreSQLで20万パーティションのテーブルにSQLを投げる - Qiita
これは、PostgreSQL Advent Calendar 2017の16日目の記事です。 はじめに 以前の記事で、パーティション数が多いほどプラン生成時間が長くなることを、パーティション数0〜1000で確認しました。今回は、20万パーティションを作成したい気分だったので、パーティションを1000ずつ20万まで作成ながら、各パーティション数でのプラン生成時間を確認します。 パーティションの作成 ネイティブ・パーティショニング機能を使い、以下のようなパーティションを作成します。パーティションにはレコードを格納せず、空のままとします。PostgreSQLのバージョンは10.1(を改造したもの1)です。 -- (親)テーブル CREATE TABLE test (key INT, val TEXT) PARTITION BY LIST (key); -- パーティション CREATE TABL
PostgreSQLの内部構造と監視の話 - そーだいなるらくがき帳
Geeks Who DrinkとPostgreSQL Conference Japan 2017での資料です。 nulab.connpass.com PostgreSQL Conference Japan 2017 (2017-11-03) | 日本PostgreSQLユーザ会 詳しく知りたい人は下記の本がおすすめです。 ただし注意点は9.3相当なのでプロセスの仕組みがちょっと違います。 待望の新刊出ました！10系ベースなのでぜひ読んでみてください。 ※2018/10/07 追記 読み応えのある内容になったかなと思います。レベル感で言えばOSS DB Goldの試験出る範囲です。特に内部構造は覚えて置いて損は無いでしょう。 speakerdeck.com 内部構造の中で取り扱っていないところにAUTOVACUUM、TOASTとレプリケーションがあります。AUTOVACUUMはPostgre
PostgreSQLの実行計画を読み解くための参考資料集 - ぱと隊長日誌
はじめに PostgreSQLは商用DBに比べて書籍が少なく、まとまった情報が入手しにくいです。また、有志の方がPostgreSQLに関する資料を公開していますが、散在しており、せっかくの有益な情報にアクセスしにくい状況にあります。 そこで、本エントリではPostgreSQLの実行計画に焦点を絞り、公開されている有用な資料（書籍含む）をまとめました。読み返したい資料を探しやすくするため、内容のポイントも併せて紹介してます。 本エントリをきっかけに、これらの資料がさらに活用されることを願っています。 前提 各資料の前提としているPostgreSQLのバージョンは異なることにご注意ください。調査対象のPostgreSQLのバージョンが異なれば、状況は変わっているかもしれません。 各資料には内容の重複があり、ほぼ同一内容の場合もあります。重複している内容についてはポイントから割愛することがありま
今こそ知りたい、2大OSSデータベースのMySQLとPostgreSQLの違いについて話をしてきた - そーだいなるらくがき帳
去年書いたSoftwareDesignを題材にお話してください！って言われたので話してきました。 下の特集記事は１年経った今も現役で読める内容なので興味がある人はぜひ読んでみてください。 またRDBアンチパターンという連載をしていますのでこちらもあわせてご確認くださいっ！ gihyo.jp そして当日の資料はこちらです。 SoftwareDesignにしっかりとMySQLとPostgreSQLの違いについては触れているのでそこでは触れていない、ハマりどころや初めて両方のDBを知ったと言う人向けのカジュアルは部分を攻めました。 またDBだけの勉強会ですので普段説明するようなところは省略し、できるだけ経験談やコアの話に注力したつもりです。 このへんは資料に含まれて居ないので当日居た人たちだけの特典ですね！！ ということで実は今月は登壇3週連続だったのですが一段落しました。 来週はAWS Sum
PL/Pythonで独自の集約関数を作成する
先月、PostgreSQLアンカンファレンスで「PL/Pythonで独自の集約関数を作ってみる」という発表をしました。 本エントリでは、その詳細について紹介させていただきます。 ■なぜPL/Pythonで集約関数なのか？ 既に広く知られている通り、PostgreSQLではさまざまなプログラミング言語でプロシージャ／ファンクションをユーザが定義することができます。 では、なぜPL/Pythonで集約関数なのでしょうか？ まず1つ目の理由としては、Pythonとデータ処理が非常に相性が良い、ということが挙げられます。古くから統計解析でRが使われてエコシステムが発展してきたのと同じように、最近ではPythonを取り巻くデータ分析に関するエコシステムが大きくなり、データ分析に関するさまざまな処理をPythonで行えるようになってきています。 2つ目の理由としては、データ処理と集約関数というのは切っ
pg_bulkload: プロジェクト ホームページ
pg_bulkload は PostgreSQL 向けの高速データロードユーティリティです。 pgFoundry のページより、ダウンロード、 ドキュメントの入手、バグレポート、メーリングリストの閲覧・購読などが行えます。 Here is an English page. ドキュメント 高速データローダ: pg_bulkload ドキュメント 一定の制約条件の下で大量のデータを高速にロードするためのプログラムです。 オプションツール: pg_timestamp ドキュメント タイムスタンプ文字列のパースのオーバヘッドをスキップするための追加モジュールです。 性能測定結果 COPY と pg_bulkload の比較のため、以下の条件で測定を行いました。 PostgreSQL サーバは、基本的なチューニングを済ませた状態です。 テーブル定義 TPC-C ベンチマークの簡易実装である DBT-
2017年の開発ロードマップについて考える - KaiGaiの俺メモ
あけましておめでとうございました。（やや出遅れ感） 新年という事で、この一年、どういった技術開発に取り組んでいきたいかをざーっと書き出してみる事にする。 これらのうち、いくつかはPostgreSQL本体機能の強化を伴うものであったりするので、ある程度計画的にモノゴトを進めないといけないワケで…。 PG-Strom v2.0 先ず最優先で取り組むのが、PostgreSQL v9.6への対応。 CPUパラレル実行と、新しいオプティマイザへの対応でかなり大きなアーキテクチャ上の変更を伴ったものの、全体としてはよりシンプルな設計に落とし込む事ができている。 ちなみに、現状だとこの程度までは動くようになっている。 集約演算がGroupAggregateとGpuPreAggの二段階に分解されており、GpuPreAggはGatherの配下で並列に動作している事に注目。 postgres=# EXPLAI
エルザ・ジャパン様の対応が神レベルだった件 - KaiGaiの俺メモ
雑文です。 現在取り組んでいる SSD-to-GPU ダイレクト機能の実装には、PostgreSQL/PG-Strom側の機能拡張だけれなく、NVMe SSDからGPU RAMへのDMAを実行する Linux kernel ドライバの開発が必要になる。 Linux kernelにはDMAを実行するためのインフラが既に多数揃っているので、ドライバの開発自体はそれほど大仕事ではないのだが、GPUがその機能に対応している必要がある。 NVIDIA提供のドキュメントによると、 GPUDirect RDMA :: CUDA Toolkit Documentation GPUDirect RDMA is available on both Tesla and Quadro GPUs. と、あり、いわゆるコンシューマ向け廉価製品であるGTXでは対応していない。 対応していないというのは、GPU上のRAM
Mvcc Unmasked
Mvcc Unmasked BRUCE MOMJIAN This talk explains how Multiversion Concurrency Control (MVCC) is implemented in Postgres, and highlights optimizations which minimize the downsides of MVCC. https://momjian.us/presentations Creative Commons Attribution License Last updated: June 2024 1 / 90 Unmasked: Who Are These People? https://www.flickr.com/photos/danielsemper/ 2 / 90 Unmasked: The Original Star Wa
DB 設計時のサイズ見積り[最新版] - Qiita
こんにちは、すっかり秋ですね！@yone098 です。 みなさんDBの設計してますか？ DB設計時のサイズ見積り 以前はてなダイアリーで書いた記事は5年前のものであり、リンクが切れているものがあるので最新版として MySQL, PostgreSQL, Oracle, SQLServer におけるDB設計時のサイズ見積りをまとめ直しました。 URL内のバージョン表記を変えると以前のバージョンの情報になります。 MySQLは、あまり情報に変化は無かったので Excel でマクロなどを作成して自社で自動算出出来るようにするのが良いと思います。 データタイプごとに必要な要求ストレージが決まっているのでレコードサイズが決まり、あとは要件次第で何レコードになるかを予測します。 データタイプごとに必要な記憶容量 テーブルの最大サイズ関連 http://dev.mysql.com/doc/refman/5
![DB 設計時のサイズ見積り[最新版] - Qiita](https://cdn-ak-scissors.b.st-hatena.com/image/square/f42e24e40ddeea81bc76c98ccc1f982252cd6b3c/height=288;version=1;width=512/https%3A%2F%2Fqiita-user-contents.imgix.net%2Fhttps%253A%252F%252Fcdn.qiita.com%252Fassets%252Fpublic%252Farticle-ogp-background-412672c5f0600ab9a64263b751f1bc81.png%3Fixlib%3Drb-4.0.0%26w%3D1200%26mark64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZ3PTk3MiZoPTM3OCZ0eHQ9REIlMjAlRTglQTglQUQlRTglQTglODglRTYlOTklODIlRTMlODElQUUlRTMlODIlQjUlRTMlODIlQTQlRTMlODIlQkElRTglQTYlOEIlRTclQTklOEQlRTMlODIlOEElNUIlRTYlOUMlODAlRTYlOTYlQjAlRTclODklODglNUQmdHh0LWFsaWduPWxlZnQlMkN0b3AmdHh0LWNvbG9yPSUyMzIxMjEyMSZ0eHQtZm9udD1IaXJhZ2lubyUyMFNhbnMlMjBXNiZ0eHQtc2l6ZT01NiZzPWM5ZmIwOTA1Y2UwNjU4NDA0MzRmOTZlMmI2NDFlMGU1%26mark-x%3D142%26mark-y%3D57%26blend64%3DaHR0cHM6Ly9xaWl0YS11c2VyLWNvbnRlbnRzLmltZ2l4Lm5ldC9-dGV4dD9peGxpYj1yYi00LjAuMCZoPTc2Jnc9NzcwJnR4dD0lNDB5b25lMDk4JTQwZ2l0aHViJnR4dC1jb2xvcj0lMjMyMTIxMjEmdHh0LWZvbnQ9SGlyYWdpbm8lMjBTYW5zJTIwVzYmdHh0LXNpemU9MzYmdHh0LWFsaWduPWxlZnQlMkN0b3Amcz1iZDkzOTdmMGQ3NWNhMGM4M2I3NmMxNjM4ODQ2OWQxMA%26blend-x%3D142%26blend-y%3D436%26blend-mode%3Dnormal%26txt64%3DaW4g5qCq5byP5Lya56S-QWJieQ%26txt-width%3D770%26txt-clip%3Dend%252Cellipsis%26txt-color%3D%2523212121%26txt-font%3DHiragino%2520Sans%2520W6%26txt-size%3D36%26txt-x%3D156%26txt-y%3D536%26s%3D6f836c4a275f61471b9e3f73ef123bda)
GO 言語で PostgreSQL につなぐ - おいぼれ商店
早速、実用に使いたいので、GO 言語(golang)で PostgreSQL につないでみたくなった。 課題： １．GO 言語から、PostgreSQL につなぐ。 PostgreSQL bindings for golang ２．そのためには、GO 言語から、外部の C ライブラリを呼び出す必要がある。 C library(libpq) binding for golang. いい加減だが、なんとかクリア。 追記：github においてみた。 I put PostgreSQL binding for golang to github. --> github:go-pg $ git clone git://github.com/oibore/go-pg.git go-pg $ cd go-pg/src $ make $ ./runnner まず、C で PostgrSQL のライブラリ l
Inside PostgreSQL Kernel アップタイム・テクノロジーズ 永安 悟史
Inside PostgreSQL Kernel アップタイム・テクノロジーズ 永安 悟史 Copyright 2014 Uptime Technologies, LLC. All rights reserved. 1 今日の目標 • RDBMSとはどのようなテクノロジーなのかを知る • その中で使われている理論について知る • PostgreSQLでどのように実装されているのかを知る • 今後の研究等においてPostgreSQLを題材とする場合に、と っかかりとなりそうなポイントを知る Copyright 2014 Uptime Technologies, LLC. All rights reserved. 2 自己紹介 • 略歴 – 1997年よりインターネットベンチャーにてネットサービス開発・運用に従事。 – 2004年より（株）ＮＴＴデータにて、並列分散データベース
PostgreSQL 9.3リリース記念 FDWで本当のデッドロックにはまってみよう - interdb’s blog
2013年9月9日、いきなりPostgreSQL9.3がリリースされた。 それを記念してFDWを使って本当のデッドロック状態をつくって遊んでみようと思う。 準備 サーバを２台準備する。サーバはtest1とtest2とする。 test1 PostgreSQLとpostgres_fdwをインストールし、データベースtestdbを作る。 $ cd contrib/postgres_fdw $ make && make install $ cd /usr/local/pgsql $ ./bin/createdb testdb 次に、CREATE EXTENSIONでpostgres_fdwを呼び込み、テスト用のテーブルaとbを作る。 testdb=# CREATE EXTENSION postgres_fdw; CREATE EXTENSION testdb=# CREATE TABLE a (i
長年の議論に終止符 -- MySQL、MariaDB、PostgreSQLのオプティマイザ/エクゼキュータ比較 - interdb’s blog
https://mariadb.com/kb/en/optimizer-switch/にあるように、MariaDBのオプティマイザはかなり改良されている。 では、MariaDBのオプティマイザ/エクゼキュータはどの程度優秀か、４つのSELECT文の実行を通してMySQLと(ついでにPostgreSQLと)比較してみる。 (2014.12.3追記：オプティマイザについては省略してますが、こんな本がでます。) 結論を先にいえば「MySQLは検索が速い」というのは都市伝説。MariaDBはがんばってるけどPostgreSQLにはまだまだ及ばず。 ＊念のため。これはベンチマークじゃないよ、オプティマイザ/エクゼキュータの機能比較です。 自分で再確認したい場合はこちらにスクリプト群と実験のやり方を簡単に書いたので参照のこと。 調査環境 同一マシンにMySQL5.6.14、MariaDB10.0.4、
PostgreSQLの共有バッファ(shared_buffer)とMySQLのバッファプール(buffer_pool)のメカニズム比較 - interdb’s blog
PostgreSQLとMySQLのバッファについて。 PostgreSQLのバッファマネージャ 詳細はこちらをみて頂くとして、PostgreSQLのバッファマネージャは、２００５年リリースのバージョン8.1で大幅に変わった。 以下の表をみて頂くとわかるようにページ置換アルゴリズムは、8.0まではリストで実装したLRUとそのバリエーションであったが、8.1から配列で実装したClockSweep方式になった。 ページ置換アルゴリズムとロックの変遷 バージョン ページ置換アルゴリズム バッファマネージャのロック 方式 説明 PostgreSQL での呼称 説明 7.4まで [〜2004] LRU "Least Recently Used"の略称。最もオーソドックスなアルゴリズム。 BufMgrLock 排他ロックのみ。ページの入れ替えだけでなく、読み取りでも排他ロックをかける*1。 8.0.0〜
第一回 中国地方DB勉強会の資料
エレクトロニック・サービス・イニシアチブのWebシステムのコンサルタントのブログです。Webシステムを対象としたセキュアコーディング／セキュアプログラミング、SAMM、ソースコード検査、Webシステム開発、パフォーマンスチューニングの技術支援、コンサルティング、セミナー開催、書籍などの執筆、PROVE for PHPの開発、PHP4.x/5.xレガシーPHPセキュリティパッチサービスなどを行っています。 ブログのサブタイトルを「書かない日記」としているのは、ブログを始めた時にあまり書かないつもりで始めたのでこのサブタイトルになっています。 氏名：大垣 靖男 私が記述したブログ中のコードは記載が無い場合はMITライセンスです。その他のコードは参考リンクなどのライセンス情報を参照ください。 ご依頼・ご相談は info@es-i.jp まで。
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GPGPUがPostgreSQLを加速する （PostgreSQLカンファレンス2014）
PostgreSQLのパラレル化に向けた取り組み@第30回(仮名)PostgreSQL勉強会
内部構造から学ぶPostgreSQL 設計・運用計画の鉄則 | Gihyo Digital Publishing … 技術評論社の電子書籍