PostgreSQL 18の新機能「B-treeインデックスのスキップスキャン」 | フューチャー技術ブログ
PostgreSQL18連載の6本目の記事です。 PostgreSQL 18がリリースされました。リリースされた機能のうち私は「B-treeインデックスのスキップスキャン」機能が気になったので、機能の特徴を深堀りしつつ、実際の挙動を確認してみます。 B-treeインデックスのスキップスキャンとは複合インデックス（複数の列で構成されるインデックス）の利用効率を劇的に向上させる新しいスキャン方法です。 従来の課題PostgreSQLでは、例えば(列A, 列B)という順番で複合インデックスを作成した場合、これまではWHERE句に先頭の「列A」の条件がないと、インデックスを効率的に使えませんでした。 例えば、WHERE 列B = 'hoge'というクエリでは、せっかくの (列A, 列B) インデックスをうまく使えず、結果としてテーブル全体をスキャン（シーケンシャルスキャン）してしまう、あるいは、イ
PostgreSQL インサイド ～ PostgreSQLに関する富士通の情報がここに ～ | 富士通
OSS（オープン・ソース・ソフトウェア）データベースの企業利用をお考えのお客様必見！ 代表的なOSSデータベースである「PostgreSQL（ポストグレスキューエル）」をビジネスで本格利用したいと考えるお客様が増えています。しかしOSSデータベースには「企業ユースに耐えうる信頼性・可用性の確保」「情報漏えいなどのセキュリティ対策」「トラブル時のサポート体制確保」など検討しなければならない課題があるのも事実です。そこで、富士通ではPostgreSQLを企業利用するために技術面、サポート面から全面的にバックアップ！PostgreSQLを安心して利用できる体制を整えています。 本ページではPostgreSQLの運用ノウハウや導入いただいたお客様の声（導入事例）やテクニカルキーパーソンへのインタビュー記事、対談、PostgreSQLコミュニティー活動への参加などをとおして当社のPostgreSQL
排他制御のためだけに Redis 渋々使ってませんか？データベース単独でアドバイザリーロックできるよ！
トランザクション分離レベルについての教養があったほうがこの記事の内容を理解しやすいため，必要に応じてまず以下を参照されたい。 背景 以前， Qiita で以下の記事を投稿した。今回の議題に直接的な関係はないが，関連している部分があるため引用する。 MySQL/Postgres とも， MVCC アーキテクチャの恩恵で， SELECT と UPDATE は基本的には競合しない。 単一レコードのシンプルな UPDATE でも排他ロックされ，排他ロック中のレコードへの UPDATE での変更操作は トランザクション分離レベルによらず ブロックされる。UPDATE 文に含まれる WHERE 句での検索もブロックされ，これはブロックされない SELECT による検索とは別扱いになる。 但し UPDATE 文の WHERE 句上で，更新対象をサブクエリの SELECT から自己参照している場合は例外。
PostgreSQLの実行計画の実行順とコスト・実行時間の累積 - ぱと隊長日誌
はじめに PostgreSQLの実行計画の読み解き方は公式マニュアルで説明されています。PostgreSQL 10 でのリンクを示します。 14.1. EXPLAINの利用 ですが、若干分かり辛い個所があるため、本エントリでは以下の観点に着目して補足することにします。 ノードの実行順 コストの累積 実行時間の累積 本エントリの引用は特記無い場合、 PostgreSQL 10 マニュアル の上記ページから引用（一部追記）しています。 ノードの実行順 原則ルール ノードの実行順は以下の原則に従って決まります。 ネストのより深いノードを優先する（右→左） ネストが同じレベルであれば先のノードを優先する（上→下） ただし、必ずしもこの実行順となるわけではありません。これを例で確認します。 EXPLAIN SELECT * FROM tenk1 t1, tenk2 t2 WHERE t1.uniqu
PostgreSQLは20年間どのようにfsyncを間違って使っていたか - 聴講メモ -
TL;DR 聴講メモ Intro into durability PostgreSQLのCHECKPIONT CHECKPOINT中にエラーが発生したら？ fsyncへの2つの間違った期待 なぜ今になって問題が明らかになってきた？ そもそもなぜBufferd I/Oなのか？ どうやって直すかか 参考リンク 質疑 最後に 先日PostgreSQLの新しいマイナーバージョンがリリースされました。このマイナーリリースでメインとなる修正は「fsync周りのバグ修正」で、このバグは間違ったfsyncに対する間違った認識から約20年間存在してたバグということで注目されていました。 このバグについてPostgreSQLのコミッタ(Tomas Vondra氏)が解説しているセッションが、先々週開催されたFOSDEM 2019でありました。私もFOSDEM 2019に参加していたのですがその際は裏セッション
PostGISのよく使う機能をまとめた - Analyze IT.
PostGISの中でも頻繁に使用する機能について調べたので、参照用にSQLとその使用方法についてまとめておきます。 GISは空間参照系や楕円体のあたりなど技術的にもマニアックだが、とりあえず理解している範囲内で基本的なことをメモ。 PostGISについて PosgreSQLには地理情報に関する機能を集めたPostGIS呼ばれる拡張がある。メリデメは以下の通り。 メリット 複雑な集計操作を豊富な関数で処理でき、GIS基盤のミドルウェアとして利用可能。 データベースに格納できるので既存のデータとの結合やデータの共有が容易。 毎回必要に応じて集計すればよいので、粒度や集計単位の異なるshpファイルをたくさん持たなくてもよくなる。 QGIS等とも相性がよく、手軽にSQLで集計して主題図を記述可能。 デメリット 毎回集計するのでメモリに乗るデータなら普通にGISで処理した方が早いかも。 データベース
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
