PostgreSQLの行レベルセキュリティ(RLS)が実行計画に与える影響を確認してみた | DevelopersIO
マルチテナントなECサイトの注文データをイメージしています。tenant_nameのカラムにテナント名が入り、このカラムとDBユーザーの一致を行セキュリティポリシーよってチェックするようなイメージです。 テストデータ等の準備 それでは検証環境を準備していきましょう。今回の検証にはPostgreSQLバージョン11.11を利用しています。 まずはテーブルを作成 CREATE TABLE orders ( id SERIAL PRIMARY KEY, tenant_name text, product_code text, order_date timestamp ); CREATE TABLE 続いてマルチテナント用のDBユーザーを作成 CREATE ROLE user01 LOGIN; CREATE ROLE CREATE SCHEMA "saas"; CREATE SCHEMA GRAN
パーティショニング : 使い方 | Let's POSTGRES
1. UPDATE, DELETE へのルールの定義 8.1 以前では UPDATE, DELETE に対して『ルール (RULE)』の定義が必要です。古いバージョンでは検索条件による自動的な絞込みが行われないため、検索を効率化するためにルールを用いて不要なパーティションを除外してやる必要があるのです。 この作業には手間がかかると思いますので、作業が自動化された 8.2 以降を使うことをお勧めします。 2. constraint_exclusion による SELECT, UPDATE, DELETE の自動化 設定パラメータ constraint_exclusion が追加され、SELECT は 8.1 以降で、UPDATE, DELETE は 8.2 以降で、絞込みが自動的に行われるようになりました。constraint_exclusion = on を設定します。ただし、デフォルトの
運用で役立つツールpg_repackのご紹介 - Qiita
この記事は PostgreSQL Advent Calendar 2015 - Qiita の9日目です。 8日目は osapon さんに書いていただきました。 この記事では、PostgreSQLを運用する上で役立つかもしれないツールの一つ pg_repack を紹介したいと思います。 pg_repackとは pg_repack はPostgreSQLの拡張ツール（エクステンション）の一つで、肥大化したテーブルやインデックスを再編成し、さらに指定したインデックスにしたがってレコードを並び替えることができます。 PostgreSQLの CLUSTER や VACUUM FULL コマンドと違って、pg_repackは処理の間対象テーブルへの排他ロックを保持し続けないため、オンライン中に動作させることができます。 どういうことなのか、説明していきますね。 テーブルやインデックスの肥大化 Pos
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
