要約 PostgreSQL のベンチマーク試験コマンドである pgbench を利用して、トランザクション(TX)分離レベル毎のパフォーマンス測定にチャレンジしました。 残念ながら、今回の検証手法でTX分離レベルのパフォーマンスを比較することに意味がないと言わざるを得ない結果となりました。 ただ、この過程で得られた知見は今後の検証の糧になると考えています。そこで、検証記録をここに公開します。 検証環境 Windows の Hyper-V による仮想マシンを検証環境としました。本来は物理マシンを使うのが理想なのですが、機材を準備できなかったためです。 ホスト プロセッサ Intel Core i5-6600 CPU @ 3.30GHz メモリ 20.0 GB OS Windows 10 Pro バージョン 1909 Hyper-V プロセッサ 4個の仮想プロセッサ メモリ 8.0 GB OS
用途 時間計測したいけど、結果の行表示とか余計なものは全くいらない、ってケースありますよね。性能検証やってるときとか。 何百行何千行も取れるようなSQL流すと、表示するのも萎える。 pager有効だと「--More--」って出て止まる。これは「q」で残りの表示はスキップできるけど、それもめんどくさい。 pager無効にすれば余計な操作はいらなくなるけど、表示処理が重いし。 結論 psqlでログインして「\timing」で実行時間表示モードをONにした後、以下を実行します。 その1:メタコマンド「\g」を使って、/dev/nullにリダイレクトする。 SELECT ...(任意のクエリ) \g |> /dev/nullWindowsのコマンドプロンプトだと、Nullへのリダイレクトは「>nul」、Powershellだと「> $null」が該当するらしいのですが、これ使うと「The synt
このページでは PostgreSQL のトランザクション(Transaction)、Multi Version Concurrency Control(MVCC)、スナップショット(Snapshot)の仕組みを説明する。 PostgreSQL の他の記事へのインデックスはここ。 更新履歴 (2016.04.30) 作成。 (2016.09.16) データ定義言語(DDL)のトランザクションを追加。 (2016.09.28) データ定義言語(DDL)の MVCC アンセーフ動作を追加。 (2017.04.07) Combo Command ID の説明が間違っているのを修正。 目次 1. はじめに 2. トランザクション分離レベル(Transaction Isolation Level) 3. Serializable 以外の分離レベルの実現方法 3.1 トランザクションとと可視性(Visi
バグの発見 原因解析 - RECOVERYHISTORYファイルとはなにか?- RECOVERYHITORYファイルのその後は? まとめ 本バグの影響は? 私自身PostgreSQL本体の開発やバグ修正を何度か行っているのですが、最近リカバリ機能周りで面白いバグを修正したので、バグの発見から原因の特定、修正まで実際に行ったことを紹介しようと思います。これからPostgreSQLに貢献していきたい、開発を始めたいという方に参考になると嬉しいです。 本バグはすでに修正されているため、再現したい方は9.5.19以前、9.6.15以前、10.10以前、11.5以前のどれかを使うか、開発用ブランチを使う場合は、コミットdf86e52cace2c413よりも古いコードを利用してください 本記事ではPostgreSQLの開発用ブランチ(materブランチ)を使用しています。PostgreSQLのソースコ
前回おさらい 仮説1 - 削除失敗? - 仮説1の検証 仮説2 - 削除後に再度作られた?- exitArchiveRecovery関数の後、いつRestoreArchivedFile関数が呼ばれるのか? まとめ PostgreSQLのリカバリ周りにあったバグ修正について、発見から修正までに実際に行ったことを紹介しています。今回は原因究明編です。前回をまだ読んでいない方は前回の記事を先に読むことをおすすめします。 前回おさらい 前回はRECOVERYHISTORYファイルがなぜ作られるのか、そして作られた後どうなるのか?について調査しました。 そしてソースコードを確認した所、RECOVERYHISTORYファイルは作られた後、KeepFileRestoredFromArchive関数にて名前が変えられたり、exitArchiveRecovery関数で削除(unlink)されていました。 仮
インストールから機能・仕組み、アプリ作り、管理・運用まで PosgreSQLの基本を一通り学べる定番入門書 PostgreSQLはオープンソースのリレーショナルデータベース管理システム(RDBMS)です。Linux、macOSといったUNIX系OSはもちろんのこと、Windowsにも対応しています。本書は、初めてPostgreSQLに触れる、あるいはそもそもデータベースに触れるのが初めてという方や、ちょっと使ったことはあるけどもう少し詳しく知りたいという方に向けた入門書です。第4版では、PostgreSQL 11をベースに全面的な改訂を行い、新旧問わずPostgreSQLの基本として初学者が押さえておくべきポイントを選別しています。 日ごろからPostgreSQLと深く関わっている執筆陣が、豊富な経験と知識をもとに、そのインストール方法、SQLの使い方から、アプリケーションの作成、そして運
PostgreSQLでのSELECTなどで対象のレコードを早く検索するための「Index(インデックス、索引)」についてのまとめです。 🗻 お勧めスライド:PostgreSQLクエリ実行の基礎知識 PostgreSQLについて丁寧な解説がされているスライドです。PostgreSQLの実行計画を理解するのにすごく参考になりました! 😼 Index作成までの流れ いつ 新規テーブルの作成時 DBのパフォーマンス・チューニングの際 どうやって SQLの実行ログから、実行回数が多い & 実行に時間がかかるSQLを探す EXPLAINで実行計画を元に最適なindexを探す 代替案としてサマリテーブルを作ったり、キャッシュをもつことも検討 🐹 Index作成SQLのCREATE INDEXでIndexを作成できます。 -- レコードがユニークではないインデックスの場合 CREATE INDEX
特集のはじめに みなさんは普段、どのようなRDBMS(Relational Database Management System)をご利用でしょうか。昨今、OSS DB(Open Source Software DataBase)の需要は高まっており、DB-Enginesのデータベース人気ランキングでもOSS DBは商用DBに負けないほどの需要を持っています。その中でも特にRDBMSは需要が高く、OSS DBであるMySQLとPostgreSQLは幅広く利用されており、PostgreSQLは2017年に大きくランキングスコアを伸ばしています。 本特集では、2018年10月18日にリリースされたばかりのバージョン11と、現場の主力として使える10にフォーカスし、進化したPostgreSQLの魅力を余すことなくお伝えします。ぜひ、これを機にPostgreSQLの新しいバージョンにチャレンジして
本エントリは PostgreSQL Advent Calendar 2018 の Day24 の記事です。 昨日の記事は @kabaome さんによる 拡張統計情報とテーブル結合 でした。 本エントリでは、PostgreSQLのカラムナーDB拡張である cstore_fdw について、その基本的な使い方から、 DBT-3 のスキーマとクエリを使ってベンチマークをしてみた結果を解説してみます。 とは言え、私自身、cstore_fdw をそれなりに使ったのはこれが初めてですので、あまり深く踏み込めていないところもあるかと思いますが、そういったところがありましたら、コメント欄や Twitter などで補足いただけると助かります。 ■cstore_fdw とは cstore_fdw は Citus Data によって開発されているオープンソースの PostgreSQL 拡張で、PostgreSQL
上の説明内の用語の補足説明です。 バキューム:更新や削除で発生した不要な領域を再利用できるようにする処理 アナライズ:クエリの効率的な実行のために、各列のデータ分布などの統計情報を収集 ダーティページ:ファイルシステムに書き戻す必要なるデータを持ったページ PostgreSQLはクエリ処理、バッファ管理、ストレージへの書き込み制御、統計情報の収集などを複数のプロセスで実行しています。 -+= 50525 root /usr/local/opt/postgresql/bin/postgres -D /usr/local/var/postgres # マスタサーバ |--= 50536 root postgres: checkpointer process # チェックポインタ |--= 50537 root postgres: writer process # ライタ |--= 50538
こんにちは。三苫です。 この記事はTECHSCORE Advent Calendar 2014、1日目の記事です。 本日はPostgreSQL経験の長い私がMySQLのシステムを新規に構築、運用するときにハマった泣いたリストをチェックリストとして共有します。 PostgreSQLしかまともに使ったことがない人が準備不足でMySQLに突撃すると何が起こるか知っておきましょう。 @tmtms さんのMySQLユーザーがPostgreSQLを触ってみたメモと重なる部分も多いですが、逆から見た視点ということでご容赦を。 必ずチェックが必要 SQLモードをPOSTGRESQLにするのが良さそう INSERT時にエラーをスルーするような挙動を避ける 型の上限値を超えた数値をINSERTした時に、エラーを出さずに最大値をセットするような挙動を避ける (この挙動を知った当時はそれなりに衝撃でした…) GR
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く