PostgreSQLで20万パーティションのテーブルにSQLを投げる - Qiita
結果 さっそく結果です。以下は、横軸パーティション数、縦軸プラン生成時間のグラフです。 やはりパーティション数に応じてプラン生成時間は増えていき、パーティション数が20万になると単純なSQLでもプラン生成だけで10秒以上かかることを確認できました。 さて、このプラン生成時間の問題ですが、改善のパッチ2は提案されていて、バージョン11以降では解消されているかもしれません。乞うご期待！！ 付録 以降は、参考までに、プラン生成時間以外に計測した結果やパーティション作成時の注意事項などです。 パーティション作成時間 以下は、横軸パーティション数、縦軸1000パーティションの作成時間のグラフです。 パーティションの作成時間も、作成済パーティション数に応じて増えていき、19万9000のパーティションが作成済の状態で、新たにパーティションを1000作成して20万にする場合は約18分もかかることを確認でき
PostgreSQL10でテーブルパーティションへのINSERT性能が大幅Upする件 - Qiita
これはPostgreSQL Advent Calendar 2016の13日目の記事です。 はじめに PostgreSQLには、継承とトリガを利用したテーブルパーティション機能が従来からありましたが、パーティションへのINSERTが非常に遅いという問題がありました。一方、それらの従来のテーブルパーティション機能の様々な問題を解決するため、NTT OSSセンタのAmit Langoteさん(@amitlan)が中心となり、新たな改善版テーブルパーティション機能が(記事執筆時点で)開発中のPostgreSQL10に取り込まれました。PostgreSQL10では、従来版と新機能版の2つのテーブルパーティション機能を利用できることになります。 この記事では、PostgreSQL10新機能版テーブルパーティションのINSERT性能が、従来のものに比べてどれだけ改善されているのか簡単に比較検証します。
PostgreSQLで各クライアントからの接続数とその内訳を確認するSQL - Qiita
SELECT client_addr, sum(1) numconns, sum(CASE WHEN state = 'active' THEN 1 ELSE 0 END) active, sum(CASE WHEN state = 'idle' THEN 1 ELSE 0 END) idle, sum(CASE WHEN state = 'idle in transaction' THEN 1 ELSE 0 END) idle_in_transaction, sum(CASE WHEN state = 'idle in transaction (aborted)' THEN 1 ELSE 0 END) aborted, sum(CASE WHEN state = 'fastpath function call' THEN 1 ELSE 0 END) fastpath, sum(CASE
PostgreSQL の poor man's 透過的暗号化 - Qiita
-- 暗号化モジュールpgcryptoの登録 CREATE EXTENSION pgcrypto; -- 暗号化したユーザデータを格納するテーブルを作成 CREATE TABLE users_internal (id BIGINT PRIMARY KEY, name BYTEA, addr BYTEA); -- ユーザデータのテーブルにアクセスするためのビューを作成 -- ユーザ名nameと住所addrの各カラムを暗号化 -- 暗号化キーにはapplication_nameの設定値を使用 CREATE OR REPLACE VIEW users AS SELECT id, pgp_sym_decrypt(name, current_setting('application_name')) "name", pgp_sym_decrypt(addr, current_setting('appl
PostgreSQLにおけるロケールの影響調査 - Qiita
PostgreSQLでの、ロケールの違い(今回は、ロケールC、ja_JP.UTF-8、en_US.UTF-8の違い)による影響を調べます。 【注意】 この記事では、ロケールの影響をMacOS上で確認しました。異なる環境・OSでは、記事とはロケールの影響が異なる可能性があります。 各ロケールのデータベースの作成 エンコーディングUTF-8、ロケールC、ja_JP.UTF-8、en_US.UTF-8の3つのデータベースを作成します。 CREATE DATABASE locale_c TEMPLATE template0 ENCODING 'UTF-8' LC_COLLATE 'C' LC_CTYPE 'C'; CREATE DATABASE locale_jp_utf8 TEMPLATE template0 ENCODING 'UTF-8' LC_COLLATE 'ja_JP.UTF-8' L
クエリチューニング: GROUP BY から LATERAL への書き換え - Qiita
「ユニークキーの GROUP BY」 を 「LATERAL」 に書き換えることで、クエリを性能改善できる可能性があります。 ここでは、非常にシンプルな書き換えの例を示します。 テーブルの準備 まずは、以下のような「部署」、「書籍」、「部署ごとの書籍在庫数」を管理する3つのテーブルを準備します。 なお、「書籍」テーブルは、データベースの状況をイメージしやすいように用意しているだけで、以降のクエリ書き換えでは特に使いません。 -- 部署のIDと名前を管理するテーブル department を作成 CREATE TABLE department (dept_id INTEGER PRIMARY KEY, name TEXT); -- 部署の情報を5件登録 COPY department (dept_id, name) FROM stdin; 1 総務部 2 開発部 3 財務部 4 企画部 5 購
PostgreSQLでHello World!! - Qiita
これは、PostgreSQL Advent Calendar 2015のDay2の記事です。 今回は、PostgreSQL経由で、Hello WorldのCプログラムを書いてコンパイルして実行してみたいと思います。 PostgreSQLの接続ポートだけ開いているようなサーバ上でHello Worldしたいときに使えるテクニックです！！ 以降のSQLは、すべてスーパーユーザで実行してください。 -- Hello Worldのソースを保存するテーブルを作成します。 CREATE TABLE hello_source (line serial, code text); -- Hello WorldのCプログラムの実行結果を保存するテーブルを作成します。 CREATE TABLE hello_result (output text); -- COPY FROM stdinで、Hello World
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
PostgreSQLのパーティショニング機能とLOCK TABLEの影響範囲の確認 - Qiita