PostgreSQLのソースコードをWebAssemblyバイナリとしてビルドしたことで、Node.jsなどのJavaScriptランタイムやWebブラウザ上で（ほぼ）フル機能のPostgreSQLを実行可能にした「PGlite」が公開されました。 PGliteはPostgreSQLのCのソースをEmscriptenでコンパイル PostgreSQLはオープンソースの代表的なリレーショナルデータベースであり、C言語で開発されています。 PGliteはこのPostgreSQLのCのソースコードのビルドにEmscriptenコンパイラを使用してWebAssemblyバイナリとして出力、JavaScript/TypeScriptからライブラリとして呼び出せるようにしたものです。 ただしEmscriptenでコンパイルされたプログラムは新しいプロセスをフォークできないため、PGliteはPostg
【Unit4 ブログリレー3日目】 こんにちは，エムスリーエンジニアリンググループの榎田です．数学とテレビゲームが好きです． 今回は，Unit4 で運用している "Docpedia" というサービスで実施した SQL チューニングの実例を2つご紹介します．普段の私が意識していなかった， RDBMS の内部機構に関する話が登場して面白かったので，今回の記事を書きました． なお，本稿で扱う議論はすべて PostgreSQL 11.x 以上を対象としており，特にその他の RDBMS で同様の動作をするかは確認していません．定性的な挙動に共通するものはあるかもしれませんが，ここで述べた話はそのままは通らないであろうことをお断りさせてください*1． プロダクトについて index なしで意外と耐えたが，耐えきれなかった話 実際の SQL とテーブル定義 原因の分析 対応策 SELECT DISTIN
306185This graph is amazing to me: Of course Intel has Xeon processors that have pushed single core performance higher than these laptop-oriented Intel results. But look at that big cluster below 5 clients, showing how long they've been stuck in the same performance range when power and heat is limited. I mentioned last time Intel had only doubled performance in the 8 years of MacBook models I loo
要約 技術的な話だけ教えて、という方のために先に結論だけ書いておきますと、PostgreSQLはクエリを実行した時点で全レコードの情報を一気に読んできてヒープを埋めてしまう場合がある、ということ話です。 たとえば、ResultSet#nextメソッドを使いながら処理を回すようなコードを書いて、少ないヒープでも処理できるようにするのは常套手段だと思いますが、そういうコードを書いていても一気にヒープを消費してしまうことがあるのです。詳しくはこのドキュメントを見てください。 https://jdbc.postgresql.org/documentation/head/query.html#query-with-cursor ことの発端 ちょっと仕事でJava + jOOQ + PostgreSQLで、DBのデータを集計するようなバッチ処理を書いてまして、もちろん俺様の書いたコードにバグなんてある
前職に帰属する文書ではあるが、自分が書いたものを振り返りながら以下に時系列順にまとめておこうと思う。 アスタミューゼ社では、開発やデザインに関する社内勉強会を週1で持ち回りで昔から行っており、この内容を外に出すだけでも多少プレゼンスが上がるのになぁ、、、じゃあ、やってみようか、ということで始めたのが所謂エンジニアブログでした。 主導したこともあり、記念すべき一発目のエントリを書かせてもらったのですが、メンバー間で色々と検討しながら作ったエンジニアブログなので、そのプロセスやノウハウをせっかくなので出してみようと、1回目からあまりエンジニアリングに関係のない内容になってしまったのも良い思い出w オンプレ (本番) と AWS (ステージング) で動いていたデータやサービス環境を、GCP に移していくことになるのですが、夜間にほとんど働いていないステージング環境のサーバは止めてしまえばいいんじ
こんにちは。並河(@namikawa)です。 新型コロナウイルスが終息していくことを祈り、弊社もリモートワーク体制に移行しておりまして、私自身もほぼ自宅で過ごしている日々です。弊社では、従前よりフルリモートワークを遂行しているメンバーが数名いますので、各人のリモートワークへの移行も割とすんなり出来たのではないかと感じています。(細かい課題意識はもちろんありますが) さて、閑話休題。 このブログでも散々話題に出ているかと思うのですが、弊社では技術や投資にまつわるデータを大量に保有しておりまして、それぞれのデータの特性や用途によって、データストアを使い分けています。 その中でも、RDB には PostgreSQL が以前より活用されていまして、今日のエントリの趣旨は、この PostgreSQL の基礎ベンチマーク数値をバージョン毎に差異があるかを確認してみた記録となります。 ベンチマークの取得
2018/10/18 NECソリューションイノベータ(株) 近藤 太樹 PGECons 勉強会#2 パラレルクエリ 1 Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved. Agenda パラレルクエリとは？ パラレルクエリはいつ使う？ パラレルクエリには何が必要？ パラレルクエリの落とし穴！？ リソースが足りない場合 大きいテーブルどうしの結合 パラレルクエリを使用したら思わぬ伏兵が!? 皆さんからの質問にお答えします! 2 Copyright © PostgreSQL Enterprise Consortium, All Rights Reserved. パラレルクエリとは？ パラレルクエリの概要 3 Copyright © PostgreSQL Enterprise Con
※ このエントリは、はてなグループ終了に伴う、サブブログからの引越エントリ(2016/05)です。 ※ 情報が古い可能性もありますので、ご留意ください。 結論から言うと、問題なくサポートされていてバックアップできた。 pg_basebackup のドキュメントの最後の注意書きには、以下の記載がある。 注意 このバックアップには、設定ファイルとサードパーティによりディレクトリに格納された追加ファイルを含む、データディレクトリとテーブル空間内のすべてのファイルが含まれます。 データディレクトリ内には通常のファイルとディレクトリのみが許され、シンボリックリンクや特殊デバイスファイルは許されません。 PostgreSQLがテーブル空間を管理する方式のため、すべての追加テーブル空間のパスはバックアップをリストアした時に常に同一でなければなりません。 しかし主データディレクトリは他の場所に設置すること
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? RDBMS といっても、SQLiteをシングルユーザで使ってたり、ORMやRESTful APIでWrapされた状態で使っていると、SQL問い合わせのできる「ファイル」という感覚になるかもしれません。 その感覚で PostgreSQL を使うとしばしば落とし穴にはまります。 DBMSは大変なのだ DBMSは昔から同時多発の更新要求を矛盾無くさばくトランザクション処理が要件でした。 この要求の苛烈さ・複雑さに思いを馳せるには、"Transaction Isolation Level", "トランザクション隔離性水準", "トランザクション
OSC 2019 Osakaの登壇資料です。
経緯 @soudai1025 さんの以下のエントリを読んでいて、 PostgreSQLのレプリケーションのコンフリクトについて 補足したくなり、 細かいけど、実際にコンフリクトするのはスレーブ側でのSELECTとそのSELECTしている行を物理削除するWALの適用（その他にもある）。SELECTのロックとUPDATEのロックは通常のクエリ処理でも競合しないようになっている。 PostgreSQLのレプリケーションのコンフリクトについてhttps://t.co/O4kEcoUVR3 — Masahiko Sawada (@sawada_masahiko) December 27, 2017 とか マスタ側での物理削除を遅らせるために、vacuum_defer_cleanup_ageではマスタ側が、消せるようになった行も少し待って（あとで）物理削除するようなる。レプリケーションスロットとか、h
データベース運用改善のヒント！コア開発者直伝のPostgreSQL 10の7つの新機能 全国のPostgreSQL使いエンジニアが待ちに待った、バージョン10。新機能の中から、特に“運用”に役立つ7の新機能を、PostgreSQLの専門家、そして開発者である澤田雅彦さんにピックアップして解説してもらいました。 2017年10月5日、全国のPostgreSQL使いエンジニアが待ちに待った、バージョン10（安定版）がリリースされました。「今後、自分の開発業務に導入していきたい」と考えている方も多いでしょう。 今回は、PostgreSQLの専門家、そして開発者である澤田雅彦さんに、新機能の中でも特に“運用”に役立つ7の新機能をピックアップして解説してもらいました。これを読めば、現場ですぐに役立つPostgreSQL 10（以下、バージョン10）の知識が身につきます！ < PostgreSQL:
FATAL: terminating connection due to conflict with recovery というエラーについて前書いてたけど、 PostgreSQLのFATAL: terminating connection due to conflict with recovery - seikoudoku2000のブログ 今更ながらに2015のRDS postgresqlのsessionを見てたら、2014の時よりしっかりと説明がされてたので、更新 & 自分の文字での情報を増やしてみた。 AWS re:Invent 2015 | (DAT402) Amazon RDS PostgreSQL: Lessons Learned & New Features - YouTube この問題は、以下の３つのパラメータで対応可能。 vacuum_defer_cleanup_age v
PostgreSQL Advent Calendar 2014 の 13日目です。 Advent Calendar を今年もやってみたいと思って、枠が空いていたので飛び込んでみました。 昨日は osapon さんの libpqxx を使ってみたでした。 概要 PostgreSQL のパフォーマンスチューニングは大きく下記に分かれます。 システムチューニング SQL チューニング ここでは Linux 上で動かしていることを前提に、それぞれ説明します。 システムチューニング システムチューニングの概要 システムチューニングとは、OS または PostgreSQL の設定を変更することです。 それぞれ順に説明します。 OS チューニング PostgreSQL では特にメモリ関連でOSパラメータを設定変更すると、高速化効果が得られます。 特に下記のカーネルパラメータに注意します。 vm.dirt
SRA OSS, Inc. 日本支社 石井 達夫 pgbenchとは pgbenchはPostgreSQLに同梱されているシンプルなベンチマークツールです。最初のバージョンは筆者により作成され、日本のPostgreSQLメーリングリストで1999年に公開されました。その後pgbenchはcontribという付属追加プログラムとして、PostgreSQLのソースコードとともに配布されるようになりました。どのバージョンでPostgreSQLに取り込まれたのかはPostgreSQL付属のドキュメント(HISTORY)には書かれていないので定かではないのですが、コミットログを見ると、おそらく2000年にリリースされたPostgreSQL 7.0で導入されたと思われます。その後数多くの改良がたくさんの人によって行われ、現在に至っています。 pgbenchを利用することにより、自分の使っているPost
PostgreSQL Advent Calendar 2012（全部俺）のDay 1です。 初日は、まずPostgreSQLを使い始める際の基本的なお作法である初期設定について簡単にまとめてみます。 PostgreSQLは、パラメータの設定を変更せずにデフォルトの設定のまま使い始めても、もちろん動くことは動くのですが、後からいろいろと問題が出てくることもありますし、特に性能関連のパラメータのデフォルト値はあまりに小さく、チューニング云々以前の問題だったりします。 というわけで、私が普段PostgreSQLをインストールして使い始める時、開発機であってもいくつかパラメータを初期設定するようにしています。 使い始める前に設定から入るのは確かに面倒なのですが、最初に設定が必要なパラメータは少数（今回紹介するのは5つ）ですので、まずは最初に必要最低限の設定をしてから使い始めましょう、というのが本エ
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
こんにちは、虎塚です。 前回は、RDSでのDBアクセスログの管理方法をご紹介しました。今回はもう少し踏み込んで、RDS for PostgreSQLを対象に具体的なログ関連の設定項目についてまとめました。 DBログの取得/運用についての設計をするにあたり、大切なのは「ログの利用目的」です。一方、どんなことを決めてDBの設定に落とす必要があるかを、設定項目からボトムアップで見てみるのも、DBMSを理解する上ではよいかと思います。 DBログ設定の項目を検討する前の前提知識 RDSでは、DBの設定項目をパラメータグループで設定します。ひとつひとつの項目を確認する前に、知っておいたほうがよいことを紹介します。 engine-default値の意味 パタメータグループには、engine-defaultと表示されている設定項目があります。 値が「engine-default」になっている設定項目には、
このブログに限り完全に著作権を放棄します(あくまでこのブログだけ。他のブログ、および下の英語文書は範囲外)。勝手に使ってよし。2016.12.20 公開した文書のごく一部を、翻訳して公開。(BLOGにするにあたり、構成は変えた。) http://www.interdb.jp/pg 概要 checkpoint_segmentsが廃止され、WALファイル数の上限下限をmax_wal_sizeとmin_wal_sizeで指定できるようになった。 WALファイル数は(これらの制限内で)サーバの活動状況=WALファイルの消費量に合わせて変化する。あまり書き込みがなければWAL数は減少し、活発になればWAL数が増える。 保存するWAL数は基本的にリカバリに必要不可欠なものに限られ、無駄なWALファイルを溜め込む事は無くなった。 理解のための前提条件 CHECKPOINTの起動タイミング CHECKPO
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く