エムスリーエンジニアリンググループGMで、データ基盤チームの木田です。 この記事はデータ基盤チーム & Unit9（エビデンス創出プロダクトチーム） ブログリレー3日目の記事です。前回は橋口さんの データ整備の「曖昧さ」に立ち向かう、ドメインエキスパートと協業するための実践的Tipsでした。 本日は、既存のPostgreSQLのさるテーブル (レコード数 100億超) に対して、差分データをSQLで抽出してBigQueryに連携するための索引追加をしたときの経験を元に、PostgreSQLの巨大テーブルに対してFlywayを使用してインデックスを安全に追加する方法についていくつかのテクニックを紹介します。 背景 ナイーブな実装の問題点 CREATE INDEX CONCURRENTLYの使用 Flywayから実行する時の注意点 タイムアウトへの対処 一時領域不足 インデックスサイズを抑える
背景 PostgreSQLのランダムデータ生成方法 uuid createではgetrandom()を使っていた 実際どれくらい違うのか？ PostgreSQLでもgetrandom()が使えるのか？ getrandom()のvDSO実装でUUID生成を比べてみる vDSO実装のgetrandomを使ってUUIDを生成してみる 参考資料 以前PostgreSQL 18でUUIDv7がサポートされたという記事を書きました。今回は現在取り組んでいるUUIDv7の生成を早くするための改善について、その背景や検証内容についてです。 背景 UUIDの生成速度が気になったきっかけは、PostgreSQLで色々なUUIDv7生成方法を比較していた時に、PostgreSQL 18で導入される予定のuuidv7()関数とpgrxで自前で作ったUUIDv7生成関数の性能比較をしていたときでした。 Postgr
PostgreSQL18連載の6本目の記事です。 PostgreSQL 18がリリースされました。リリースされた機能のうち私は「B-treeインデックスのスキップスキャン」機能が気になったので、機能の特徴を深堀りしつつ、実際の挙動を確認してみます。 B-treeインデックスのスキップスキャンとは複合インデックス（複数の列で構成されるインデックス）の利用効率を劇的に向上させる新しいスキャン方法です。 従来の課題PostgreSQLでは、例えば(列A, 列B)という順番で複合インデックスを作成した場合、これまではWHERE句に先頭の「列A」の条件がないと、インデックスを効率的に使えませんでした。 例えば、WHERE 列B = 'hoge'というクエリでは、せっかくの (列A, 列B) インデックスをうまく使えず、結果としてテーブル全体をスキャン（シーケンシャルスキャン）してしまう、あるいは、イ
All these instances run on the same (or extremely similar) Intel CPUs. We include the i7i instance to show what Postgres is capable of with fast, local NVMe drives. This is what we use for PlanetScale Metal and have seen amazing performance results for Postgres 17. Many other cloud providers only provide a form of network-attached storage, whereas we provide both options. Each server is warmed wit
What is pipelining in Postgres? Pipelining is a client-side feature supported by the network protocol that basically consists of not waiting for the results of previously sent queries before sending the next. This increases the throughput in two ways: The client, network and server can work in parallel. For instance, the network may transmit the results of the (N-1)th query while the server execut
There are books & many articles online, like this one arguing for using Postgres for everything. I thought I’d take a look at one use case - using Postgres instead of Redis for caching. I work with APIs quite a bit, so I’d build a super simple HTTP server that responds with data from that cache. I’d start from Redis as this is something I frequently encounter at work, switch it out to Postgres usi
The PostgreSQL Global Development Group today announced the release of PostgreSQL 18, the latest version of the world's most advanced open source database. Translations of this press release are available in the PostgreSQL 18 press kit. PostgreSQL 18 improves performance for workloads of all sizes through a new I/O subsystem that has demonstrated up to 3× performance improvements when reading from
PostgreSQL 18 was stamped earlier this week, and as usual there’s a lot of improvements. One of the big architectural changes is asynchronous I/O (AIO), allowing asynchronous scheduling of I/O, giving the database more control and better utilizing the storage. I’m not going to explain how AIO works, or present detailed benchmark results. There have been multiple really good blog posts about that.
We're excited to share the 1.0 release of pg_duckdb, an open-source PostgreSQL extension that brings DuckDB's vectorized analytical engine directly inside PostgreSQL. You can think of it as adding a turbo engine to your PostgreSQL database–ready to run efficient, ad hoc queries while PostgreSQL continues doing what it does best: transactional workloads for your production app. Pg_duckdb embeds a D
This Part 1 (of a 2-part series) is a practical, hands-on, applicable approach to database indexes. We’ll cover what B Trees are with a focus on deeply understanding, and internalizing how they store data on disk, and how your database uses them to speed up queries. This will set us up nicely for part 2, where we’ll explore some interesting, counterintuitive ways to press indexes into service to a
Want to learn more about unlimited IOPS w/ Metal for Postgres and Vitess? Talk to Solutions By Andres Taylor, Dirkjan Bussink, Harshit Gangal, Nick Van Wiggeren, Noble Mittal, Rohit Nayak, Roman Sodermans, Shlomi Noach, Sam Lambert | August 11, 2025 Today, we are announcing Neki — sharded Postgres by the team behind Vitess. Vitess is one of PlanetScale’s greatest strengths and contemporary Vitess
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
