no-function-on-column-in-join-or-where ルールは、JOIN や WHERE の条件でカラムに関数を適用している箇所を検出します。インデックスカラムへ関数を適用しているケースの検出を念頭に置いたルールです。（コーディング規約）
-- NG: カラムに関数を適用しており、インデックスが効かない SELECT id FROM orders WHERE to_char(created_at, 'YYYYMMDD') ='20260101'; -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Functions in JOIN or WHERE conditions can prevent index usage; rewrite without wrapping the column. created_at (no-function-on-column-in-join-or-where)
-- OK: 定数のみに関数を適用する SELECT id FROM orders WHERE created_at >= to_date('20260101', 'YYYYMMDD');
no-not-in
no-not-in ルールは、NOT IN の使用を検出します。NOT IN はサブクエリの結果に NULL が 1 つでも含まれると結果が 1 行も返らなくなるという落とし穴が知られています。代わりに NOT EXISTS の利用を促すルールです。（コーディング規約）
-- NG: orders.user_id に NULL が 1 件でもあると、このクエリは 1 行も返さない SELECT id FROM users WHERE id NOTIN (SELECT user_id FROM orders); -- ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ -- Avoid using NOT IN; prefer NOT EXISTS or other alternatives to handle NULL correctly. (no-not-in)
-- OK: NOT EXISTS なら NULL があっても意図どおりに動く SELECT id FROM users WHERENOTEXISTS (SELECT1FROM orders WHERE orders.user_id = users.id);
-- NG: バインドパラメータ（/*user_id*/）に対応するサンプル値が欠けている SELECT id FROM users WHERE id =/*user_id*/; -- ^^ -- Sample value for bind parameter is missing. (missing-two-way-sample)
-- OK: バインドパラメータに対するサンプル値がある SELECT id FROM users WHERE id =/*user_id*/10;
特に、アプリから接続する際のドライバ設定に気をつける必要があります。Java から Microsoft JDBC Driver for SQL Server を使う場合、sendStringParametersAsUnicode=true（デフォルト）2により、パラメータが nvarchar として送られます。この状態でテーブル列が varchar だと、クエリごとに型変換が発生し、インデックスが効きにくくなります。プロジェクト初期に文字列型を統一すること（日本語を扱うなら原則 nvarchar など）、ドライバ設定と DB 定義をセットで設計レビューすることを考慮しておくことが重要です。
PostgreSQL の search_path は複数のスキーマを順番に探索する仕組みです。たとえば myapp, public のように設定しておけば、スキーマ名を省略したときにその順番でスキーマが解決されます。
一方、SQL Server にはこれに相当する複数スキーマ探索の仕組みはありません。代わりにあるのは、ユーザーごとに 1 つだけ設定されるデフォルトスキーマです。スキーマ名を省略した場合は、まずそのデフォルトスキーマが参照され、見つからなければSQL Server のデフォルトスキーマである dbo が参照されます。
SQL Server の dbo は PostgreSQL の public に相当します。原則として public と同様に、ユーザーが業務用オブジェクトを dbo に直接作成することは避け、アプリケーション用のスキーマを別途作成してそこに配置するのが望ましいです。
SQL Server の悲観ロックは PostgreSQL よりもロックされる範囲が広くなりやすいため注意が必要です。
PostgreSQL の SELECT ... FOR UPDATE は、最終的に条件に一致した行だけをロックします。対して SQL Server で WITH (UPDLOCK) を用いた場合、条件に合う行をスキャンする途中で読み込んだ行にもロックが及ぶことがあります6。そのため、PostgreSQL と同じ感覚で使うと、更新対象ではない行までブロックしてしまい、システム全体の並行性を下げるリスクがあります。
SQL Server には PostgreSQL にない概念として「ロックエスカレーション8」があります。SQL Server では、行単位のロックを管理するためにメモリを消費します。1 つのトランザクションで大量の行ロックを取得すると、メモリ効率を保つためにロックを行単位からテーブル単位に自動的に昇格させる仕組みがあり、これがロックエスカレーションです。デフォルトの閾値は約 5,000 行で、これを超えるとテーブル全体がロックされます。
PostgreSQL では、WITH 句を定義してメインクエリ内で同じ CTE を複数回参照した場合、デフォルトではマテリアライズされるため 1 回しか計算されません9。そのため、重い処理を WITH 句に切り出して再利用するテクニックが有効な場面があります。
一方 SQL Server における WITH 句はインラインビューとして扱われます。結果セットは物理的に保持されないため、メインクエリ内で複数回参照すると、その回数分だけ元テーブルへのスキャンや再計算が行われます10。
PostgreSQL の感覚で重い処理を 1 回で済ませる目的で WITH 句を多用すると、SQL Server ではかえって遅くなることがあります。複数回参照する重い処理がある場合は、WITH 句ではなく一時テーブル（#temp テーブル）に結果を格納するなどの代替アプローチを検討するのが安全です。
このツールでやっているのは、SQLをトークン分割して構文解析をしてASTを組み立てて、エラーチェックなどをしつつシンプルな命令列に変換してから、最適化を行なって最終的にGoなどのコードを生成する、という動きをします。生成時に文字列結合（CONCAT, ||）、キャスト（CAST( AS type), ::type）や日付関数などは生成先に合わせて吸収するとかもしてます。まあコンパイラですね。パーサコンビネータから自作してます。ツール自体は結構なロジックの量になっていますが、静的なコードを生成するようにしており、アプリケーションが太らないようにランタイムの依存はほとんどないという思想でやっています。最後のコード生成部分はなるべく薄くしているので、いろんな言語に対応させたいです。
CREATE TABLE self_reference ( id BIGINT GENERATED BYDEFAULTASIDENTITYPRIMARY KEY,
-- 自分自身（value）を参照して値を生成しようとする仮想列 "self_value" int GENERATED ALWAYS AS (self_value +1) VIRTUAL ); ERROR: cannot use generated column "self_value" incolumn generation expression LINE 5: "self_value" int GENERATED ALWAYS AS (self_value +1) VI... ^ DETAIL: A generated column cannot reference another generated column.
ドキュメントにも、 The generation expression can refer to other columns in the table, but not other generated columns.（生成式はテーブル内の他の列を参照できますが、他の生成列を参照できません。）とあるので、記載通りの挙動です。
CREATE TABLE m_user ( user_id BIGINT GENERATED BYDEFAULTASIDENTITYPRIMARY KEY, first_name TEXT, last_name TEXT, email TEXT, email_lower TEXT GENERATED ALWAYS AS (LOWER(email)) STORED, full_name TEXT GENERATED ALWAYS AS (last_name ||' '|| first_name) VIRTUAL );
-- 生成列で利用されているカラムをリネームする postgres=# ALTER TABLE m_user RENAME COLUMN first_name TO given_name; ALTER TABLE postgres=# ALTER TABLE m_user RENAME COLUMN email TO email_address; ALTER TABLE
postgres=# \d m_user Table "public.m_user" Column| Type |Collation| Nullable |Default ---------------+--------+-----------+----------+-------------------------------------------------------------- user_id |bigint||not null| generated bydefaultasidentity given_name | text ||| last_name | text ||| email_address | text ||| email_lower | text ||| generated always as (lower(email_address)) stored full_name | text ||| generated always as ((last_name ||' '::text) || given_name) Indexes: "m_user_pkey" PRIMARY KEY, btree (user_id)
リネームにも追随してくれるの、気が効いていますね。賢い。
15. 利用しているカラムをDROP COLUMNしたときどうなるか
格納生成列、仮想生成列それぞれで利用しているカラムを、DROPできるか試しました。
CREATE TABLE m_user ( user_id BIGINT GENERATED BYDEFAULTASIDENTITYPRIMARY KEY, first_name TEXT, last_name TEXT, email TEXT, email_lower TEXT GENERATED ALWAYS AS (LOWER(email)) STORED, full_name TEXT GENERATED ALWAYS AS (last_name ||' '|| first_name) VIRTUAL );
-- 格納生成列で利用されているカラムを削除 postgres=# ALTER TABLE m_user DROPCOLUMN email; ERROR: cannot dropcolumn email oftable m_user because other objects depend on it DETAIL: column email_lower oftable m_user depends oncolumn email oftable m_user HINT: Use DROP ... CASCADE todrop the dependent objects too.
-- 仮想生成列で利用されているカラムを削除 postgres=# ALTER TABLE m_user DROPCOLUMN first_name; ERROR: cannot dropcolumn first_name oftable m_user because other objects depend on it DETAIL: column full_name oftable m_user depends oncolumn first_name oftable m_user HINT: Use DROP ... CASCADE todrop the dependent objects too.
例えば、(x, y)に対するインデックスがあり、クエリ条件がWHERE y = 7700である場合、B-treeインデックススキャンはスキップスキャン最適化を適用できる可能性があります。これは一般的に、クエリプランナが、テーブルで利用可能なインデックスを考慮した上で、Nのすべての可能な値（またはインデックスに実際に格納されているすべてのxの値）に対してWHERE x = N AND y = 7700という検索を繰り返すことが最も高速なアプローチであると予測する場合に発生します。
docker run --name pg18-handson -e POSTGRES_PASSWORD=mysecretpassword -p 5432:5432 -d postgres:18
コンテナの起動を確認。
$ docker ps CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 0806a36cb87c postgres:18 "docker-entrypoint.s…" 8 seconds ago Up 7 seconds 0.0.0.0:5432->5432/tcp, :::5432->5432/tcp pg18-handson
psqlコマンドで入ってみると、、しっかりと動いてることが確認できたので次に進みます。
$ docker exec -it pg18-handson psql -U postgres psql (18.0 (Debian 18.0-1.pgdg13+3)) Type "help" for help.
postgres=#
テーブルの作成と検証用データの投入
ordersテーブルを作成し、100万件のデータを投入します。
CREATE TABLE orders ( order_id SERIAL PRIMARY KEY, order_status TEXT NOT NULL, -- 'pending', 'processing', 'shipped', 'delivered', 'cancelled' の5種類 customer_id INTEGERNOT NULL, order_date TIMESTAMPTZ NOT NULL, order_details TEXT );
postgres=*# EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 123; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------------------------- Index Scan using idx_orders_status_customer on orders (cost=0.42..418.60 rows=100 width=36) (actual time=0.052..0.250 rows=93.00 loops=1) Index Cond: (customer_id = 123) Index Searches: 11 Buffers: shared hit=126 Planning Time: 0.062 ms Execution Time: 0.276 ms
Index Scanが行われており、 0.276msで応答しました。高速ですね。ただし、実行計画にはスキップスキャンを示す表記が登場しないため、厳密にはスキップスキャンを行ったか否かを判断できないのが悩ましいところです。今回のクエリは複合インデックスの2列目に対してのみ等価条件を指定しており、1列目データ群はカーディナリティが低いため、”おそらく”スキップスキャンが行われているだろうと考えられます。
次に、Seq Scanが採択された場合にどのような結果となるかも試してみます。
postgres=*# SET LOCAL enable_indexscan = off; SET postgres=*# SET LOCAL enable_bitmapscan = off; SET postgres=*# EXPLAIN ANALYZE SELECT * FROM orders WHERE customer_id = 123; QUERY PLAN -------------------------------------------------------------------------------------------------------------------------- Gather (cost=1000.00..15164.33 rows=100 width=36) (actual time=0.363..18.606 rows=93.00 loops=1) Workers Planned: 2 Workers Launched: 2 Buffers: shared hit=8946 -> Parallel Seq Scan on orders (cost=0.00..14154.33 rows=42 width=36) (actual time=0.141..14.359 rows=31.00 loops=3) Filter: (customer_id = 123) Rows Removed by Filter: 333302 Buffers: shared hit=8946 Planning Time: 0.062 ms Execution Time: 18.625 ms
18.625msで応答しており、Index Scanよりも大幅に遅い結果になりました。
PostgreSQL 17 の場合
次は同様の検証をPostgreSQL 17にて実施してみます。
下準備
以下コマンドでコンテナを立ち上げた後は18の時と同じ手順でデータを投入していきます。
docker run --name pg17-handson -e POSTGRES_PASSWORD=mysecretpassword -p 5433:5432 -d postgres:17
hoge=> EXPLAIN SELECT*FROM childs WHERE parent_id =8887212; QUERY PLAN -------------------------------------------------------------------------------------------------------- Index Scan using childs_parent_id_idx on childs (cost=0.57..18009.19rows=5951 width=130) Index Cond: (parent_id =8887212) (2rows)
現在稼働しているシステムでは SSD ボリュームの DB を使用しています。A 案は SSD ボリュームで実施する分にはデメリットが特になさそうだったため、開発環境でしばらく運用して問題が発生しないことを確認した上で、採用することにしました。
ただし、A 案を採用しても Index Scan が選ばれやすくなるだけで、統計情報自体が改善される訳ではありません。そのため、指定される parent 数が多いと結局 Seq Scan が選ばれてしまう、という状況でした。 よって、統計情報を改善する施策である B 案と C 案についても検討し、いずれかの方法も合わせて採用する必要がありました。
/* Count the number of values we found multiple times */ summultiple = 0; for (nmultiple = 0; nmultiple < track_cnt; nmultiple++) { if (track[nmultiple].count == 1) break; summultiple += track[nmultiple].count; }
/* * where f1 is the number of distinct values that occurred * exactly once in our sample of n rows (from a total of N), * and d is the total number of distinct values in the sample. ... */ int f1 = nonnull_cnt - summultiple; int d = f1 + nmultiple; double n = samplerows - null_cnt; double N = totalrows * (1.0 - stats->stanullfrac); double stadistinct;
/* N == 0 shouldn't hhogeen, but just in case ... */ if (N > 0) stadistinct = (n * d) / ((n - f1) + f1 * n / N); else stadistinct = 0;
create table {テーブル名} (id01 bigintnot null , id02 text not null , id03 text not null , id04 text not null , id05 text not null) with(autovacuum_enabled =false, toast.autovacuum_enabled =false); alter table table01 add constraint pk_table01 primary key (id01);
データ作成
insert into table01 (select generate_series(1,1000000),generate_series(1,1000000)%2,generate_series(1,1000000)%3,generate_series(1,1000000)%4,generate_series(1,1000000)%5);
create table {テーブル名} (id01 bigintnot null , id02 text not null , id03 text not null , id04 text not null , id05 text not null) with(autovacuum_enabled =false, toast.autovacuum_enabled =false); alter table table01 add constraint pk_table01 primary key (id01);
データ作成
insert into table01 (select generate_series(1,1000000),generate_series(1,1000000),generate_series(1,1000000),generate_series(1,1000000),generate_series(1,1000000));
create table {テーブル名} (id01 bigintnot null , id02 text not null , id03 text not null , id04 text not null , id05 text not null) with(autovacuum_enabled =false, toast.autovacuum_enabled =false); alter table table01 add constraint pk_table01 primary key (id01);
データ作成
insert into table01 (select generate_series(1,1000000),generate_series(1,1000000),generate_series(1,1000000),generate_series(1,1000000),generate_series(1,1000000));
Index Scan using table01_idx1 on table01 (cost=0.41..8.43rows=1 width=16) (actual time=0.678..181.715rows=999999.00 loops=1) Index Cond: (id02 ='1'::text) Index Searches: 1 Buffers: shared hit=7352 read=844 Planning: Buffers: shared hit=36 read=1 Planning Time: 0.794 ms Execution Time: 215.249 ms
-> Index Scan using customers_pkey on customers c (cost=0.27..0.35 rows=1 width=16) (actual time=0.001..0.001 rows=0.15 loops=438) Index Cond: (id = o.customer_id) Filter: (city = 'Tokyo'::text) Rows Removed by Filter: 1
EXPLAIN (ANALYZE, VERBOSE, BUFFERS) SELECT category, product_name, amount, ROW_NUMBER() OVER (PARTITIONBY category ORDERBY amount DESC) as rank, AVG(amount) OVER (PARTITIONBY category) as avg_amount FROM sales ORDERBY category, rank;
QUERY PLAN ----------------------------------------------------------------------------------------------------------------------------------------- Incremental Sort (cost=102.22..158.29 rows=1000 width=64) (actual time=1.589..2.132 rows=1000.00 loops=1) Output: category, product_name, amount, (row_number() OVER w1), (avg(amount) OVER w2) Sort Key: sales.category, (row_number() OVER w1) Presorted Key: sales.category Full-sort Groups: 3 Sort Method: quicksort Average Memory: 29kB Peak Memory: 29kB Pre-sorted Groups: 3 Sort Method: quicksort Average Memory: 45kB Peak Memory: 45kB Buffers: shared hit=12 -> WindowAgg (cost=80.46..103.83 rows=1000 width=64) (actual time=1.199..1.821 rows=1000.00 loops=1) Output: category, product_name, amount, (row_number() OVER w1), avg(amount) OVER w2 Window: w2 AS (PARTITION BY sales.category) Storage: Memory Maximum Storage: 37kB Buffers: shared hit=9 -> WindowAgg (cost=68.85..88.83 rows=1000 width=32) (actual time=0.958..1.313 rows=1000.00 loops=1) Output: category, amount, product_name, row_number() OVER w1 Window: w1 AS (PARTITION BY sales.category ORDER BY sales.amount ROWS UNBOUNDED PRECEDING) Storage: Memory Maximum Storage: 17kB Buffers: shared hit=9 -> Sort (cost=68.83..71.33 rows=1000 width=24) (actual time=0.949..0.991 rows=1000.00 loops=1) Output: category, amount, product_name Sort Key: sales.category, sales.amount DESC Sort Method: quicksort Memory: 69kB Buffers: shared hit=9 -> Seq Scan on public.sales (cost=0.00..19.00 rows=1000 width=24) (actual time=0.007..0.095 rows=1000.00 loops=1) Output: category, amount, product_name Buffers: shared hit=9 Execution Time: 2.192 ms (26 rows)
ウィンドウ関数の定義がWindow: w1 AS (PARTITION BY sales.category ORDER BY sales.amount ROWS UNBOUNDED PRECEDING)のように詳細に表示されます。また、Storage: Memory Maximum Storage: 17kBでメモリ使用量も確認できます。
EXPLAIN ANALYZE SELECT user_id FROM users WHERE user_id BETWEEN100AND200;
QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------- Index Only Scan using users_user_id_idx on users (cost=0.29..6.30 rows=101 width=4) (actual time=0.014..0.110 rows=101.00 loops=1) Index Cond: ((user_id >= 100) AND (user_id <= 200)) Heap Fetches: 202 Index Searches: 1 Buffers: shared hit=206 Planning: Buffers: shared hit=3 Planning Time: 0.065 ms Execution Time: 0.122 ms (9 rows)
QUERY PLAN --------------------------------------------------------------------------------------------------------------------- Function Scan on generate_series (cost=0.00..1.00 rows=100 width=4) (actual time=0.017..0.022 rows=100.00 loops=1) Planning Time: 0.045 ms Execution Time: 0.057 ms (3 rows)
SET enable_hashjoin = off; EXPLAIN SELECT*FROM orders o JOIN customers c ON o.customer_id = c.id;
QUERY PLAN ------------------------------------------------------------------------------------------------- Merge Join (cost=0.57..830.06 rows=10000 width=67) Merge Cond: (o.customer_id = c.id) -> Index Scan using orders_customer_idx on orders o (cost=0.29..498.28 rows=10000 width=18) -> Index Scan using customers_pkey on customers c (cost=0.28..194.28 rows=5000 width=49) (4 rows)
What’s New in PostgreSQL 18 - https://www.sqlpassion.at/archive/2025/09/29/whats-new-in-postgresql-18/
Crunchy Data: Get Excited About Postgres 18 - https://www.crunchydata.com/blog/get-excited-about-postgres-18
Going down the rabbit hole of Postgres 18 features - https://xata.io/blog/going-down-the-rabbit-hole-of-postgres-18-features
Waiting for PostgreSQL 18 – Enable BUFFERS with EXPLAIN ANALYZE by default - https://www.depesz.com/2025/01/15/waiting-for-postgresql-18-enable-buffers-with-explain-analyze-by-default/
Validation Errors: testfiles/src/insert/insert_select.sql - ❌ Validation error: different kind token: Errors have occurred near the following token
Unimplemented Features: testfiles/src/delete/with.sql - ❌ Unimplemented: visit_preparable_stmt: UpdateStmt is not implemented testfiles/src/insert/insert_on_conflict.sql - ❌ Unimplemented: visit_insert_stmt(): opt_on_conflict is not implemented testfiles/src/insert/with.sql - ❌ Unimplemented: visit_preparable_stmt: UpdateStmt is not implemented testfiles/src/select/with.sql - ❌ Unimplemented: visit_preparable_stmt: UpdateStmt is not implemented testfiles/src/update/with.sql - ❌ Unimplemented: visit_preparable_stmt: UpdateStmt is not implemented
Other Errors: testfiles/src/insert/insert_returning.sql - Formatting result does not match testfiles/src/select/complement_alias.sql - Formatting result does not match testfiles/src/update/update_returning.sql - Formatting result does not match
{xcstart} { /* Set location in case of syntax error in comment */ SET_YYLLOC(); yyextra->xcdepth = 0; BEGIN(xc); /* Put back any characters past slash-star; see above */ yyless(2); }
余談
定義ファイルを見ると、これまで知らなかった書き方を知ることがあります。
一例ですが select n'1'; のように文字列の前に n というプレフィックスを付与することが定義できるというのは、この作業を通じて知りました。
{xnstart} { /* National character. * We will pass this along as a normal character string, * but preceded with an internally-generated "NCHAR". */ int kwnum;
SET_YYLLOC(); yyless(1); /* eat only 'n' this time */
kwnum = ScanKeywordLookup("nchar", yyextra->keywordlist); if (kwnum >= 0) { yylval->keyword = GetScanKeyword(kwnum, yyextra->keywordlist); return yyextra->keyword_tokens[kwnum]; } else { /* If NCHAR isn't a keyword, just return "n" */ yylval->str = pstrdup("n"); return IDENT; } }
参考
Lexical Analysis With Flex, for Flex 2.6.2: Format https://westes.github.io/flex/manual/Format.html#Format
結合性を宣言できます。 %leftで左結合、%rightで右結合、%nonassocで無結合を宣言できます。 また優先度が低い順に記載されており、この例では OR より AND の方が優先度が高いことがわかります。
/* Precedence: lowest to highest */ %left UNION EXCEPT %left INTERSECT %left OR %left AND %right NOT %nonassoc IS ISNULL NOTNULL /* IS sets precedence for IS NULL, etc */ %nonassoc '<' '>' '=' LESS_EQUALS GREATER_EQUALS NOT_EQUALS %nonassoc BETWEEN IN_P LIKE ILIKE SIMILAR NOT_LA %nonassoc ESCAPE /* ESCAPE must be just above LIKE/ILIKE/SIMILAR */
SELECT title FROM pgweb WHERE to_tsvector(title ||' '|| body) @@ to_tsquery('create & table') ORDERBY last_mod_date DESC LIMIT 10;
テーブルの中にもtsvectorを作ってあげます。
CREATE TABLE articles ( id SERIAL PRIMARY KEY, title TEXT NOT NULL, content TEXT NOT NULL, file_path TEXT NOT NULLUNIQUE, author TEXT NOT NULLDEFAULT'', created_at TIMESTAMPWITHTIME ZONE DEFAULT NOW(), processed_text TEXT NOT NULL, search_vector tsvector GENERATED ALWAYS AS ( to_tsvector('simple', coalesce(title, '') ||' '||coalesce(processed_text, '')) ) STORED );
ソースコードはgithub.com/shibukawa/pgtfsです。生成AIでサッと作りました。ライセンスはUnlicenseです。full text searchだとftsのはずですが、スペルを間違ったのでtfsになってます。CLIツールとなっています。実証実験のコードなので、インデックスのメンテナンスとか考えずに、一発投入のみ。
INSERTALL INTO M_TEST_ID1 (VALUE) VALUES (VALUE) INTO M_TEST_ID2 (VALUE) VALUES (VALUE) SELECTVALUEFROM M_TEST;
※IDENTITY列の採番方法には、GENERATED ALWAYS AS IDENTITY、GENERATED BY DEFAULT AS IDENTITYの2種類があります。詳しく説明している記事の紹介にとどめて、詳細な説明は割愛させていただきますが、本記事ではGENERATED BY DEFAULT AS IDENTITYを利用しました。
例えば次に示す2WaySQLは、前述したSQLに from 句と where 句を付加したものです。2WaySQLの条件分岐機能を使っている where 句に注目すると、通常のSQLとして解釈するためには where 句のセパレータ and または or が不足していることがわかります。
通常のSQLとしては不正な2WaySQL（フォーマット前）.sql
select 'a'as a /*IF true*/ , 'b'as b /*ELSE*/ , 'ccccccccccccccc'as c /*END*/ from some_table t where /*IF some_condition */ some_column ='value'-- 通常のSQLとして解釈するには、この位置にセパレータ（and, or）が必要 /*ELSE*/ some_column ='other_value' /*END*/ ;
select 'a'as a /*IF true*/ , 'b'as b /*ELSE*/ , 'ccccccccccccccc'as c /*END*/ from some_table t where /*IF some_condition */ some_column ='value'-- 通常のSQLとして解釈するには、この位置にセパレータ（and, or）が必要 /*ELSE*/ some_column ='other_value' /*END*/ ;
postgres=# INSERT INTO color (color_id, color_name) VALUES (3, 'Blue'); ERROR: cannot insert a non-DEFAULTvalueintocolumn "color_id" DETAIL: Column "color_id" is an identitycolumn defined as GENERATED ALWAYS. HINT: Use OVERRIDING SYSTEMVALUEto override.
脱出ハッチも用意されており、OVERRIDING SYSTEM VALUE を利用すると強制的に上書きもできます。
INSERT INTO color (color_name) VALUES ('Orange'); INSERT INTO color (color_name) VALUES ('Red');
-- OVERRIDING SYSTEM VALUEを利用（エラーにせず、IDENTITYに明示的な値を登録可能） INSERT INTO color (color_id, color_name) OVERRIDING SYSTEMVALUEVALUES (3, 'Blue'); INSERT INTO color (color_id, color_name) OVERRIDING SYSTEMVALUEVALUES (4, 'Brown');
postgres=# select*from color; color_id | color_name ----------+------------ 1| Orange 2| Red 3| Blue 4| Brown (4rows)
通常は、 OVERRIDING SYSTEM VALUE をうっかり付けて登録してしまう開発者はごく限られていると想定すると、GENERATED BY DEFAULT AS IDENTITY をSERIAL型の代わりに利用する方が、誤登録を発生させずベターだと思います。
postgres=# COPY color (color_name) FROM STDIN WITH (FORMAT csv); Enter data to be copied followed by a newline. Endwith a backslash and a periodon a line by itself, or an EOF signal. >> Orange >> Red >> Blue >> Brown >> Black >> \. >>>>>>>>COPY5
テーブルの結果です。
postgres=# select*from color; color_id | color_name ----------+------------ 1| Orange 2| Red 3| Blue 4| Brown 5| Black (5rows)
postgres=# COPY color (color_id, color_name) FROM STDIN WITH (FORMAT csv); Enter data to be copied followed by a newline. Endwith a backslash and a periodon a line by itself, or an EOF signal. >>21,Orange >>22,Red >>23,Blue >>24,Brown >>25,Black >> \. COPY5
テーブルの結果です。指定した値でcolor_idが登録されていますね。
postgres=# select*from color; color_id | color_name ----------+------------ 21| Orange 22| Red 23| Blue 24| Brown 25| Black (5rows)
\d comment; Partitioned table "public.comment" Column| Type |Collation| Nullable |Default --------------+--------+-----------+----------+------------------------------ comment_id |bigint||not null| generated always asidentity content | text ||not null| comment_date |date||not null| Partition key: RANGE (comment_date) Indexes: "comment_pk" PRIMARY KEY, btree (comment_date, comment_id) Number of partitions: 1 (Use \d+to list them.)
続いて、データ登録します。
INSERT INTO comment (content, comment_date) VALUES ('Orange', '2024-05-15'); INSERT INTO comment (content, comment_date) VALUES ('Red', '2024-05-16'); INSERT INTO comment (content, comment_date) VALUES ('Blue', '2024-05-16');
テーブルは以下のように登録されました。
postgres=# select*from comment; comment_id | content | comment_date ------------+---------+-------------- 1| Orange |2024-05-15 2| Red |2024-05-16 3| Blue |2024-05-16 (3rows)
さっと利用した感じ、特に課題は無いかなと思います。
4. 作成されたシーケンスの名称
下記のようなSQLで抽出できます。
SELECT t.relname as table_name, a.attname as column_name, s.relname as sequence_name FROM pg_class s JOIN pg_depend d ON d.objid = s.oid JOIN pg_class t ON d.refobjid = t.oid JOIN pg_attribute a ON a.attnum = d.refobjsubid AND a.attrelid = t.oid WHERE s.relkind ='S' ;
postgres=# drop sequence color_color_id_seq; ERROR: cannot drop sequence color_color_id_seq because column color_id oftable color requires it HINT: You can dropcolumn color_id oftable color instead.
CREATE TABLE color ( color_id INT GENERATED ALWAYS ASIDENTITY (STARTWITH10 INCREMENT BY1 CACHE 100), color_name VARCHARNOT NULL );
10. 文字列型とGENERATED AS IDENTITYの組み合わせ
文字列型（text型）にGENERATED ALWAYS AS IDENTITYを指定すると、いい感じの型変換により ‘1’、’2’、…といった採番がされないかと思いついたので試しました。
postgres=# CREATE TABLE color ( color_id text GENERATED ALWAYS ASIDENTITYPRIMARY KEY, color_name VARCHARNOT NULL ); ERROR: identitycolumn type must be smallint, integer, orbigint
Allow exclusion constraints on partitioned tables (Paul A. Jungwirth) § As long as exclusion constraints compare partition key columns for equality, other columns can use exclusion constraint-specific comparisons.
パーティショニングされたテーブルに排他制約を許可する（Paul A. Jungwirth） 排他制約がパーティションキー列に対して等価を比較する限り、他の列は排他制約特有の比較を使用できます。 https://www.postgresql.org/docs/17/release-17.html#RELEASE-17-UTILITY
CREATE TABLE schedule ( schedule_id SERIAL PRIMARY KEYNOT NULL, room_name TEXT NOT NULL, reservation_time tsrange NOT NULL, EXCLUDE USING GIST (reservation_time WITH&&) );
16以前のバージョンでは、パーティションテーブルの親側に定義することはできなかった
16より前のバージョンは、以下のように PARTITON BY と EXCLUDE USING を同時に宣言できませんでした。
postgres=# select version(); version --------------------------------------------------------------------------------------------------------------------- PostgreSQL 16.4 (Debian 16.4-1.pgdg120+2) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit (1row)
-- パーティションテーブルで排他制約を宣言 postgres=# CREATE TABLE reservations ( id BIGSERIAL NOT NULL, room_id INTNOT NULL, reservation_date date, start_time TIMESTAMPNOT NULL, end_time TIMESTAMPNOT NULL, CONSTRAINT reservations_pkey PRIMARY KEY (reservation_date, id), EXCLUDE USING GIST ( reservation_date WITH=, room_id WITH=, tsrange(start_time, end_time) WITH&& ) ) PARTITIONBYRANGE (reservation_date); ERROR: exclusion constraints arenot supported on partitioned tables LINE 8: EXCLUDE USING GIST (
exclusion constraints are not supported on partitioned tables とあるのがエラー部分です。
healthcare_data=# WITH datatype AS ( SELECT 'varchar(50)' AS type ) SELECT to_regtype(d.type), to_regtypemod(d.type), format_type( to_regtype(d.type), to_regtypemod(d.type) ) FROM datatype d; to_regtype | to_regtypemod | format_type -------------------+---------------+----------------------- character varying | 54 | character varying(50) (1 row)
healthcare_data=# WITH datatype AS ( SELECT 'numeric(5, 2)' AS type ) SELECT format_type( to_regtype(d.type), to_regtypemod(d.type) ) FROM datatype d; format_type -------------- numeric(5,2) (1 row)
配列型の場合
配列の場合にも、以下のように取得できています。
healthcare_data=# WITH datatype AS ( SELECT 'numeric(5, 2)[]' AS type ) SELECT format_type( to_regtype(d.type), to_regtypemod(d.type) ) FROM datatype d; format_type -------------- numeric(5,2)[] (1 row)
healthcare_data=# INSERT INTO sample_patient_info (age, heart_rate, blood_pressure) VALUES (120, 1200, 120.75); ERROR: numeric field overflow DETAIL: A field with precision 3, scale 0 must round to an absolute value less than 10^3.
/* * Add typmod decoration to the basic type name */ staticchar * printTypmod(constchar *typname, int32 typmod, Oid typmodout) { char *res;
/* Shouldn't be called if typmod is -1 */ Assert(typmod >= 0);
if (typmodout == InvalidOid) { /* Default behavior: just print the integer typmod with parens */ res = psprintf("%s(%d)", typname, (int) typmod); } else { /* Use the type-specific typmodout procedure */ char *tmstr;
tmstr = DatumGetCString(OidFunctionCall1(typmodout, Int32GetDatum(typmod))); res = psprintf("%s%s", typname, tmstr); }
/* * numeric_typmod_precision() - * * Extract the precision from a numeric typmod --- see make_numeric_typmod(). */ staticinlineint numeric_typmod_precision(int32 typmod) { return ((typmod - VARHDRSZ) >> 16) & 0xffff; }
/* * numeric_typmod_scale() - * * Extract the scale from a numeric typmod --- see make_numeric_typmod(). * * Note that the scale may be negative, so we must do sign extension when * unpacking it. We do this using the bit hack (x^1024)-1024, which sign * extends an 11-bit two's complement number x. */ staticinlineint numeric_typmod_scale(int32 typmod) { return (((typmod - VARHDRSZ) & 0x7ff) ^ 1024) - 1024; }
Amazon RDS for PostgreSQLを利用してPostgreSQL 16.3のデータベースを作成しました。大手のクラウドベンダーではマネージドサービスのDBでもPLV8に対応しています。
cf. クラウドベンダーのマネージドPostgreSQLデータベースにおける対応拡張機能
AWS: Amazon RDS for PostgreSQL
Azure: Azure Database for PostgreSQL
GCP: Cloud SQL for PostgreSQL
PLV8拡張機能をインストールします。(cf. Installing PLV8)
-- 利用可能な拡張機能を確認 select* from pg_available_extensions where name like'pl%' orderby name;
-- PLV8拡張機能をインストール create extension plv8;
-- インストールできたことを確認 その1 select* from pg_extension orderby extname;
-- インストールできたことを確認 その2 select plv8_version();
サンプルDB
今回は PostgreSQL wiki に掲載されている Pagila を利用しました。
DO ブロックでの実行
PLV8は DO による無名コードブロック実行にも対応しているため、手始めに DO ブロックで試してみます。
素朴なSQL実行の例
do $$ //SQLを実行して結果を取得 const inactives = plv8.execute(` selectcount(1)::integeras inactive_count from customer c where c.active =0 `) plv8.elog(NOTICE, `There is ${inactives[0].inactive_count} inactive members.`) $$ language plv8;
実行結果は以下です。特に問題なく期待通りの結果が得られました。
pagila=> do $$ pagila$> // SQLを実行して結果を取得 pagila$> const inactives = plv8.execute(` pagila$> select count(1)::integer as inactive_count pagila$> from customer c pagila$> where c.active = 0 pagila$> `) pagila$> plv8.elog(NOTICE, `There is ${inactives[0].inactive_count} inactive members.`) pagila$> $$ language plv8; NOTICE: There is 15 inactive members. DO
do $$ let plan, cursor try { // プリペアド文を作成 plan = plv8.prepare(` select c.customer_id, c.first_name from customer c whereexists ( select1 from rental r where c.customer_id = r.customer_id groupby r.customer_id havingcount(1) > $1 ) orderby c.customer_id `, ['integer'])
// プリペアド文を実行してカーソルを取得 cursor= plan.cursor([40]) let customer // カーソルを使ってループ while (customer = cursor.fetch()) { plv8.elog(NOTICE, `id: ${customer.customer_id}, name: ${customer.first_name}`) } } finally { // カーソルとプリペアド文は解放が必要 cursor?.close() plan?.free() } $$ language plv8;
実行結果は以下です。こちらも特に問題なく期待通りの結果が得られました。
実行結果
pagila=> do $$ pagila$> let plan, cursor pagila$> try { pagila$> // プリペアド文を作成 pagila$> plan = plv8.prepare(` pagila$> select c.customer_id, c.first_name pagila$> from customer c pagila$> where exists ( pagila$> select 1 pagila$> from rental r pagila$> where c.customer_id = r.customer_id pagila$> group by r.customer_id pagila$> having count(1) > $1 pagila$> ) pagila$> order by c.customer_id pagila$> `, ['integer']) pagila$> pagila$> // プリペアド文を実行してカーソルを取得 pagila$> cursor = plan.cursor([40]) pagila$> let customer pagila$> // カーソルを使ってループ pagila$> while (customer = cursor.fetch()) { pagila$> plv8.elog(NOTICE, `id: ${customer.customer_id}, name: ${customer.first_name}`) pagila$> } pagila$> } finally { pagila$> // カーソルとプリペアド文は解放が必要 pagila$> cursor?.close() pagila$> plan?.free() pagila$> } pagila$> $$ language plv8; NOTICE: id: 75, name: TAMMY NOTICE: id: 144, name: CLARA NOTICE: id: 148, name: ELEANOR NOTICE: id: 236, name: MARCIA NOTICE: id: 526, name: KARL DO
関数として作成して実行
CREATE FUNCTION 文を手作成
カーソルで取得する例のSQLを関数にして実行してみます。DO ブロックの代わりに CREATE FUNCTION にするだけなので、ついでに閾値を関数の引数で渡すように変更してみます。
createfunction print_top_customers(frequency integer) returns void as $$ -- ---------- 処理はほぼ同じなため記載省略 ---------- $$ language plv8 stable;
実行結果
pagila=> create function print_top_customers(frequency integer) returns void as $$ pagila$> let plan, cursor pagila$> try { pagila$> // プリペアド文を作成 pagila$> plan = plv8.prepare(` pagila$> select c.customer_id, c.first_name pagila$> from customer c pagila$> where exists ( pagila$> select 1 pagila$> from rental r pagila$> where c.customer_id = r.customer_id pagila$> group by r.customer_id pagila$> having count(1) > $1 pagila$> ) pagila$> order by c.customer_id pagila$> `, ['integer']) pagila$> pagila$> // プリペアド文を実行してカーソルを取得 pagila$> cursor = plan.cursor([frequency]) pagila$> let customer pagila$> // カーソルを使ってループ pagila$> while (customer = cursor.fetch()) { pagila$> plv8.elog(NOTICE, `id: ${customer.customer_id}, name: ${customer.first_name}`) pagila$> } pagila$> } finally { pagila$> // カーソルとプリペアド文は解放が必要 pagila$> cursor?.close() pagila$> plan?.free() pagila$> } pagila$> $$ language plv8 stable; CREATE FUNCTION pagila=> select print_top_customers(40); NOTICE: id: 75, name: TAMMY NOTICE: id: 144, name: CLARA NOTICE: id: 148, name: ELEANOR NOTICE: id: 236, name: MARCIA NOTICE: id: 526, name: KARL print_top_customers ---------------------
(1 行)
DO ブロックでの実行と同じ結果が得られました。
JavaScript実装をバンドルして CREATE FUNCTION SQL を生成
前の例では CREATE FUNCTION 文を手作成しました。そのSQLにおいて1行目と最終行以外はJSの実装です。であれば、JS部分は独立して開発して最後に CREATE FUNCTION 文を生成できれば色々捗りそうです。それをやってくれるツールであるPLV8ifyが公式ドキュメントで紹介されていますので、ここからはPLV8ifyを使った関数の開発を試してみます。
なお、 plv8ify は実際には上記でインストールされたバージョンそのものではなく、バグと思われる挙動や利便性向上をローカルで修正したものを使用しました。このため、ここより後の例ではTypeScriptで実装した関数に対して生成される CREATE FUNCTION 文の関数定義では関数名と引数名が snake_case 化されるようにしています。
PLV8関数のTS実装例
前の手作成 CREATE FUNCTION の例をTS実装にし、ついでに検索結果をログではなく戻り値として返却するように変更したものがこちらです。
fetch_top_customers.ts
/** * @plv8ify_param {integer} frequency * @plv8ify_return {setof record} * @plv8ify_volatility STABLE */ exportfunctionfetchTopCustomers(frequency: number): void { let plan!: PreparedPlan, cursor!: Cursor; try { plan = plv8.prepare(` select c.customer_id, c.first_name from customer c where exists ( select 1 from rental r where c.customer_id = r.customer_id group by r.customer_id having count(1) > $1 ) order by c.customer_id `, ['integer']);
pagila=> \i plv8ify-dist/fetch_top_customers.plv8.sql psql:plv8ify-dist/fetch_top_customers.plv8.sql:1: NOTICE: function fetch_top_customers(pg_catalog.int4) does not exist, skipping DROP FUNCTION CREATE FUNCTION pagila=> select * from fetch_top_customers(40) as (idinteger, name varchar); id | name -----+--------- 75 | TAMMY 144 | CLARA 148 | ELEANOR 236 | MARCIA 526 | KARL (5 行)
CREATEFUNCTION public.rewards_report(min_monthly_purchases integer, min_dollar_amount_purchased numeric, today date) RETURNS SETOF public.customer LANGUAGE plpgsql SECURITY DEFINER AS $_$ DECLARE last_month_start DATE; last_month_end DATE; rr RECORD; tmpSQL TEXT; BEGIN
/* Some sanity checks... */ IF min_monthly_purchases =0THEN RAISE EXCEPTION 'Minimum monthly purchases parameter must be > 0'; END IF; IF min_dollar_amount_purchased =0.00THEN RAISE EXCEPTION 'Minimum monthly dollar amount purchased parameter must be > $0.00'; END IF;
/* Create a temporary storage area for Customer IDs. */ CREATE TEMPORARY TABLE tmpCustomer (customer_id INTEGERNOT NULLPRIMARY KEY);
/* Find all customers meeting the monthly purchase requirements */
tmpSQL :='INSERT INTO tmpCustomer (customer_id) SELECT p.customer_id FROM payment AS p WHERE DATE(p.payment_date) BETWEEN '||quote_literal(last_month_start) ||' AND '|| quote_literal(last_month_end) ||' GROUP BY customer_id HAVING SUM(p.amount) > '|| min_dollar_amount_purchased ||' AND COUNT(customer_id) > '||min_monthly_purchases ;
EXECUTE tmpSQL;
/* Output ALL customer information of matching rewardees. Customize output as needed. */ FOR rr INEXECUTE'SELECT c.* FROM tmpCustomer AS t INNER JOIN customer AS c ON t.customer_id = c.customer_id' LOOP RETURN NEXT rr; END LOOP;
/* Clean up */ tmpSQL :='DROP TABLE tmpCustomer'; EXECUTE tmpSQL;
RETURN; END $_$;
上記PL/pgSQL関数を以下のようにTS実装しました。
引数追加版 rewards_report のTS実装
v8_rewards_report.ts
/** * @plv8ify_param {integer} minMonthlyPurchases * @plv8ify_param {numeric} minDollarAmountPurchased * @plv8ify_param {date} today * @plv8ify_return {setof public.customer} * @plv8ify_volatility VOLATILE */ exportfunctionv8RewardsReport( minMonthlyPurchases: number, minDollarAmountPurchased: number, today: Date, ): void { // Some sanity checks... if (minMonthlyPurchases === 0) { thrownewError('Minimum monthly purchases parameter must be > 0'); } if (minDollarAmountPurchased === 0.00) { thrownewError('Minimum monthly dollar amount purchased parameter must be > $0.00'); }
const lastMonthStart = plv8.execute(` SELECT DATE_TRUNC('month', $1::timestamp - '3 month'::interval) AS val `, [today])[0].val; const lastMonthEnd = plv8.execute(` SELECT LAST_DAY($1) AS val `, [lastMonthStart])[0].val;
// Create a temporary storage area for Customer IDs. plv8.execute(` CREATE TEMPORARY TABLE tmpCustomer (customer_id INTEGER NOT NULL PRIMARY KEY) `);
// Find all customers meeting the monthly purchase requirements plv8.execute(` INSERT INTO tmpCustomer (customer_id) SELECT p.customer_id FROM payment AS p WHERE DATE(p.payment_date) BETWEEN $1 AND $2 GROUP BY customer_id HAVING SUM(p.amount) > ${minDollarAmountPurchased} AND COUNT(customer_id) > ${minMonthlyPurchases} `, [lastMonthStart, lastMonthEnd]);
// Output ALL customer information of matching rewardees. // Customize output as needed. let plan!: PreparedPlan, cursor!: Cursor; try { plan = plv8.prepare(` SELECT c.* FROM tmpCustomer AS t INNER JOIN customer AS c ON t.customer_id = c.customer_id `); cursor = plan.cursor(); letcustomer: SQLRow; while ((customer = cursor.fetch())) { plv8.return_next(customer); } } finally { cursor?.close(); plan?.free(); }
// Clean up plv8.execute('DROP TABLE tmpCustomer'); }
前の例と同様に CREATE FUNCTION SQL を生成し関数を作成してSQLを実行しました。
pagila=> select customer_id, first_name pagila-> from v8_rewards_report(10, 40, '2022-06-22'); customer_id | first_name -------------+------------ 147 | JOANNE 158 | VERONICA 179 | DANA 366 | BRANDON 381 | BOBBY 410 | CURTIS 416 | JEFFERY 526 | KARL (8 行)
pagila=> select customer_id, first_name pagila-> from rewards_report(10, 40, '2022-06-22'); customer_id | first_name -------------+------------ 147 | JOANNE 158 | VERONICA 179 | DANA 366 | BRANDON 381 | BOBBY 410 | CURTIS 416 | JEFFERY 526 | KARL (8 行)
/** * @plv8ify_param {timestamp with time zone} date * @plv8ify_return {date} */ exportfunctionv8LastDay2( date: Date, ): Date { returndayjs(date).endOf('month').toDate(); }
このTS実装から生成した CREATE FUNCTION SQL を確認すると、インポートしている dayjs はインライン化されることが分かります。
/** * @plv8ify_param {integer} inventoryId */ exportfunctionv8InventoryInStock( inventoryId: number, ): boolean { // AN ITEM IS IN-STOCK IF THERE ARE EITHER NO ROWS IN THE rental TABLE // FOR THE ITEM OR ALL ROWS HAVE return_date POPULATED
constrentals: number = plv8.execute(` SELECT count(*) AS val FROM rental WHERE inventory_id = ${inventoryId} `)[0].val;
if (rentals === 0) { returntrue; }
constout: number = plv8.execute(` SELECT COUNT(rental_id) AS val FROM inventory LEFT JOIN rental USING(inventory_id) WHERE inventory.inventory_id = ${inventoryId} AND rental.return_date IS NULL `)[0].val;
return out <= 0; }
CREATE FUNCTION SQL を生成し関数を作成してSQLを実行すると、PLV8版とPL/pgSQL版で同じ結果が得られます。
実行結果
pagila=> select pagila-> iid, pagila-> inventory_in_stock(iid) as in_stock, pagila-> v8_inventory_in_stock(iid) as in_stock_v8 pagila-> from generate_series(1, 10) as iid; iid | in_stock | in_stock_v8 -----+----------+------------- 1 | t | t 2 | t | t 3 | t | t 4 | t | t 5 | t | t 6 | f | f 7 | t | t 8 | t | t 9 | f | f 10 | t | t (10 行)
const inventoryId = 1; expect(v8InventoryInStock(inventoryId)).toBe(true); expect(plv8.execute) .toHaveBeenNthCalledWith(1, ` SELECT count(*) AS val FROM rental WHERE inventory_id = ${inventoryId} `) .toHaveBeenNthCalledWith(2, ` SELECT COUNT(rental_id) AS val FROM inventory LEFT JOIN rental USING(inventory_id) WHERE inventory.inventory_id = ${inventoryId} AND rental.return_date IS NULL `); });
