在单个查询中获取分页行和总计数
Get paginated rows and total count in single query
核心要求：
根据指定的筛选条件 type、plan、status，查找 submission_date 的 person_id 的最新条目。可能有更多这样的过滤器，但不管怎样，到提交日期最晚 return 的逻辑是相同的。两种主要用途，一种用于 UI 中的分页查看，第二种用于生成报告。
WITH cte AS (
SELECT * FROM (
SELECT my_table.*, rank() OVER (PARTITION BY person_id ORDER BY submission_date DESC, last_updated DESC, id DESC) FROM my_table
) rank_filter
WHERE RANK=1 AND status in ('ACCEPTED','CORRECTED') AND type != 'CR' AND h_plan_id IN (10000, 20000)
)
SELECT
SELECT count(id) FROM cte group by id,
SELECT * FROM cte limit 10 offset 0;
group by 也不适用于 CTE。计数查询中所有 null 的联合可能适用于组合，但不确定。
我想将这两个合并为 1 个查询的主要原因是 table 很大，而 window 函数很昂贵。目前我使用单独的查询，它们基本上 运行 相同的查询两次。
Postgres 版本 12。
\d my_table;
Table "public.my_table"
Column | Type | Collation | Nullable
--------------------------+-----------------------------+-----------+----------
id | bigint | | not null
h_plan_id | bigint | | not null
h_plan_submitter_id | bigint | |
last_updated | timestamp without time zone | |
date_created | timestamp without time zone | |
modified_by | character varying(255) | |
segment_number | integer | |
-- <bunch of other text columns>
submission_date | character varying(255) | |
person_id | character varying(255) | |
status | character varying(255) | |
file_id | bigint | | not null
Indexes:
"my_table_pkey" PRIMARY KEY, btree (id)
"my_table_file_idx" btree (file_id)
"my_table_hplansubmitter_idx" btree (h_plan_submitter_id)
"my_table_key_hash_idx" btree (key_hash)
"my_table_person_id_idx" btree (person_id)
"my_table_segment_number_idx" btree (segment_number)
Foreign-key constraints:
"fk38njesaryvhj7e3p4thqkq7pb" FOREIGN KEY (h_plan_id) REFERENCES health_plan(id) ON UPDATE CASCADE ON DELETE CASCADE
"fk6by9668sowmdob7433mi3rpsu" FOREIGN KEY (h_plan_submitter_id) REFERENCES h_plan_submitter(id) ON UPDATE CASCADE ON DELETE CASCADE
"fkb06gpo9ng6eujkhnes0eco7bj" FOREIGN KEY (file_id) REFERENCES x12file(id) ON UPDATE CASCADE ON DELETE CASCADE
附加信息
type 的可能值为 EN 和 CR，其中 EN 约占数据的 70%。
Table 列宽 select avg_width from pg_stats where tablename='mytable'; 41 列总共 374，所以每列大约 9。
这个想法是预先向用户显示一些页面，然后他们可以通过其他参数进行过滤，例如 file_name（每个文件通常有大约 5k 个条目），type（非常低的基数）， member_add_id（高基数），plan_id（低基数，每 500k 到 100 万个条目将与一个计划 ID 相关联）。在所有情况下，业务需求都是只显示 submission_date 的一组特定计划 ID 的最新记录（对于每年完成的报告）。按 id 排序只是防御性编码，同一天可以有多个条目，即使有人编辑了倒数第二个条目因此触及 last_updated 时间戳，我们只想显示相同数据的最后一个条目。这可能永远不会发生，可以删除。
用户可以使用此数据生成 csv 报告。
下面右连接查询的解释结果：
Nested Loop Left Join (cost=554076.32..554076.56 rows=10 width=17092) (actual time=4530.914..4530.922 rows=10 loops=1)
CTE cte
-> Unique (cost=519813.11..522319.10 rows=495358 width=1922) (actual time=2719.093..3523.029 rows=422638 loops=1)
-> Sort (cost=519813.11..521066.10 rows=501198 width=1922) (actual time=2719.091..3301.622 rows=423211 loops=1)
Sort Key: mytable.person_id, mytable.submission_date DESC NULLS LAST, mytable.last_updated DESC NULLS LAST, mytable.id DESC
Sort Method: external merge Disk: 152384kB
-> Seq Scan on mytable (cost=0.00..54367.63 rows=501198 width=1922) (actual time=293.953..468.554 rows=423211 loops=1)
Filter: (((status)::text = ANY ('{ACCEPTED,CORRECTED}'::text[])) AND (h_plan_id = ANY ('{1,2}'::bigint[])) AND ((type)::text <> 'CR'::text))
Rows Removed by Filter: 10158
-> Aggregate (cost=11145.56..11145.57 rows=1 width=8) (actual time=4142.116..4142.116 rows=1 loops=1)
-> CTE Scan on cte (cost=0.00..9907.16 rows=495358 width=0) (actual time=2719.095..4071.481 rows=422638 loops=1)
-> Limit (cost=20611.67..20611.69 rows=10 width=17084) (actual time=388.777..388.781 rows=10 loops=1)
-> Sort (cost=20611.67..21850.06 rows=495358 width=17084) (actual time=388.776..388.777 rows=10 loops=1)
Sort Key: cte_1.person_id
Sort Method: top-N heapsort Memory: 30kB
-> CTE Scan on cte cte_1 (cost=0.00..9907.16 rows=495358 width=17084) (actual time=0.013..128.314 rows=422638 loops=1)
Planning Time: 0.369 ms
JIT:
Functions: 9
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 1.947 ms, Inlining 4.983 ms, Optimization 178.469 ms, Emission 110.261 ms, Total 295.660 ms
Execution Time: 4587.711 ms
您可以尝试简化查询：
SELECT DISTINCT ON (person_id) t.*
FROM my_table t
WHERE status in ('ACCEPTED', 'CORRECTED')
ORDER BY person_id, submission_date DESC, last_updated DESC, id DESC
我不确定 Postgres 是否足够聪明，可以在这种情况下使用 (person_id, submission_date DESC, last_updated DESC, id DESC, status) 上的索引，但值得一试。
您可以使用表达式上的索引来加快此过程：(status in ('ACCEPTED', 'CORRECTED'), person_id, submission_date DESC, last_updated DESC, id DESC).
编辑：
如果要按另一列排序，可以使用子查询：
SELECT t.*
FROM (SELECT DISTINCT ON (person_id) t.*
FROM my_table t
WHERE status in ('ACCEPTED', 'CORRECTED')
ORDER BY person_id, submission_date DESC, last_updated DESC, id DESC
) t
ORDER BY submission_date DESC
第一件事：你可以在同一查询中多次使用CTE的结果，这是主要的feature of CTEs.) 你所拥有的将像这样工作（同时仍然只使用一次 CTE）：
WITH cte AS (
SELECT * FROM (
SELECT *, row_number() -- see below
OVER (PARTITION BY person_id
ORDER BY submission_date DESC NULLS LAST -- see below
, last_updated DESC NULLS LAST -- see below
, id DESC) AS rn
FROM tbl
) sub
WHERE rn = 1
AND status IN ('ACCEPTED', 'CORRECTED')
)
SELECT *, count(*) OVER () AS total_rows_in_cte
FROM cte
LIMIT 10
OFFSET 0; -- see below
警告 1：rank()
rank() 可以 return 每个 person_id 和 rank = 1 多行。 DISTINCT ON (person_id)（如 Gordon 提供的那样）是 row_number() 的适用替代品 - 它适用于您，如附加信息所阐明的那样。参见：
- Select first row in each GROUP BY group?
警告 2：ORDER BY submission_date DESC
submission_date 和 last_updated 均未定义 NOT NULL。可能是 ORDER BY submission_date DESC, last_updated DESC ... 的问题请参阅：
- PostgreSQL sort by datetime asc, null first?
这些列真的应该是 NOT NULL 吗？
您回复了：
Yes, all those columns should be non-null. I can add that constraint. I put it as nullable since we get data in files which are not always perfect. But this is very rare condition and I can put in empty string instead.
类型 date 不允许空字符串。保持列可为空。 NULL 是这些情况下的正确值。按照说明使用 NULLS LAST 以避免 NULL 排在最前面。
警告 3：OFFSET
如果 OFFSET 等于或大于 CTE 编辑的行数 return，您将得到 无行，所以也没有总数。参见：
临时解决方案
解决到目前为止的所有注意事项，并根据添加的信息，我们可能会得出以下查询：
WITH cte AS (
SELECT DISTINCT ON (person_id) *
FROM tbl
WHERE status IN ('ACCEPTED', 'CORRECTED')
ORDER BY person_id, submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC
)
SELECT *
FROM (
TABLE cte
ORDER BY person_id -- ?? see below
LIMIT 10
OFFSET 0
) sub
RIGHT JOIN (SELECT count(*) FROM cte) c(total_rows_in_cte) ON true;
现在 CTE 实际上 使用了两次。 RIGHT JOIN 保证我们得到总数，不管 OFFSET。 DISTINCT ON 应该对基本查询中每个 (person_id) 仅有的几行执行 OK-ish。
但是你的行很宽。平均多宽？该查询可能会导致整个 table 的顺序扫描。索引不会帮助（很多）。所有这些对于分页 来说仍然非常低效 。参见：
您不能将索引用于分页，因为它基于从 CTE 派生的 table。而且您的分页实际排序标准仍然不清楚（ORDER BY id？）。如果分页是目标，那么您迫切需要一种不同的查询方式。如果您只对前几页感兴趣，则需要不同的查询样式。最佳解决方案取决于问题中仍然缺少的信息......
快得多
更新后的objective：
Find latest entries for a person_id by submission_date
（为简单起见，忽略 "for specified filter criteria, type, plan, status"。）
并且：
Find the latest row per person_id only if that has status IN ('ACCEPTED','CORRECTED')
基于这两个专门的指数:
CREATE INDEX ON tbl (submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC NULLS LAST)
WHERE status IN ('ACCEPTED', 'CORRECTED'); -- optional
CREATE INDEX ON tbl (person_id, submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC NULLS LAST);
运行 这个查询：
WITH RECURSIVE cte AS (
(
SELECT t -- whole row
FROM tbl t
WHERE status IN ('ACCEPTED', 'CORRECTED')
AND NOT EXISTS (SELECT FROM tbl
WHERE person_id = t.person_id
AND ( submission_date, last_updated, id)
> (t.submission_date, t.last_updated, t.id) -- row-wise comparison
)
ORDER BY submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC NULLS LAST
LIMIT 1
)
UNION ALL
SELECT (SELECT t1 -- whole row
FROM tbl t1
WHERE ( t1.submission_date, t1.last_updated, t1.id)
< ((t).submission_date,(t).last_updated,(t).id) -- row-wise comparison
AND t1.status IN ('ACCEPTED', 'CORRECTED')
AND NOT EXISTS (SELECT FROM tbl
WHERE person_id = t1.person_id
AND ( submission_date, last_updated, id)
> (t1.submission_date, t1.last_updated, t1.id) -- row-wise comparison
)
ORDER BY submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC NULLS LAST
LIMIT 1)
FROM cte c
WHERE (t).id IS NOT NULL
)
SELECT (t).*
FROM cte
LIMIT 10
OFFSET 0;
这里的每一组括号都是必需的。
这种复杂程度应该通过使用给定的索引而不是顺序扫描来从根本上更快地检索一组相对较小的顶行。参见：
- Optimize GROUP BY query to retrieve latest row per user
submission_date 最有可能是类型 timestamptz 或 date，而不是 character varying(255)
- Refactor foreign key to fields
可能会优化更多细节，但这已经失控了。您可以考虑专业咨询。
核心要求：
根据指定的筛选条件 type、plan、status，查找 submission_date 的 person_id 的最新条目。可能有更多这样的过滤器，但不管怎样，到提交日期最晚 return 的逻辑是相同的。两种主要用途，一种用于 UI 中的分页查看，第二种用于生成报告。
WITH cte AS (
SELECT * FROM (
SELECT my_table.*, rank() OVER (PARTITION BY person_id ORDER BY submission_date DESC, last_updated DESC, id DESC) FROM my_table
) rank_filter
WHERE RANK=1 AND status in ('ACCEPTED','CORRECTED') AND type != 'CR' AND h_plan_id IN (10000, 20000)
)
SELECT
SELECT count(id) FROM cte group by id,
SELECT * FROM cte limit 10 offset 0;
group by 也不适用于 CTE。计数查询中所有 null 的联合可能适用于组合，但不确定。
我想将这两个合并为 1 个查询的主要原因是 table 很大，而 window 函数很昂贵。目前我使用单独的查询，它们基本上 运行 相同的查询两次。
Postgres 版本 12。
\d my_table;
Table "public.my_table"
Column | Type | Collation | Nullable
--------------------------+-----------------------------+-----------+----------
id | bigint | | not null
h_plan_id | bigint | | not null
h_plan_submitter_id | bigint | |
last_updated | timestamp without time zone | |
date_created | timestamp without time zone | |
modified_by | character varying(255) | |
segment_number | integer | |
-- <bunch of other text columns>
submission_date | character varying(255) | |
person_id | character varying(255) | |
status | character varying(255) | |
file_id | bigint | | not null
Indexes:
"my_table_pkey" PRIMARY KEY, btree (id)
"my_table_file_idx" btree (file_id)
"my_table_hplansubmitter_idx" btree (h_plan_submitter_id)
"my_table_key_hash_idx" btree (key_hash)
"my_table_person_id_idx" btree (person_id)
"my_table_segment_number_idx" btree (segment_number)
Foreign-key constraints:
"fk38njesaryvhj7e3p4thqkq7pb" FOREIGN KEY (h_plan_id) REFERENCES health_plan(id) ON UPDATE CASCADE ON DELETE CASCADE
"fk6by9668sowmdob7433mi3rpsu" FOREIGN KEY (h_plan_submitter_id) REFERENCES h_plan_submitter(id) ON UPDATE CASCADE ON DELETE CASCADE
"fkb06gpo9ng6eujkhnes0eco7bj" FOREIGN KEY (file_id) REFERENCES x12file(id) ON UPDATE CASCADE ON DELETE CASCADE
附加信息
type 的可能值为 EN 和 CR，其中 EN 约占数据的 70%。
Table 列宽 select avg_width from pg_stats where tablename='mytable'; 41 列总共 374，所以每列大约 9。
这个想法是预先向用户显示一些页面，然后他们可以通过其他参数进行过滤，例如 file_name（每个文件通常有大约 5k 个条目），type（非常低的基数）， member_add_id（高基数），plan_id（低基数，每 500k 到 100 万个条目将与一个计划 ID 相关联）。在所有情况下，业务需求都是只显示 submission_date 的一组特定计划 ID 的最新记录（对于每年完成的报告）。按 id 排序只是防御性编码，同一天可以有多个条目，即使有人编辑了倒数第二个条目因此触及 last_updated 时间戳，我们只想显示相同数据的最后一个条目。这可能永远不会发生，可以删除。
用户可以使用此数据生成 csv 报告。
下面右连接查询的解释结果：
Nested Loop Left Join (cost=554076.32..554076.56 rows=10 width=17092) (actual time=4530.914..4530.922 rows=10 loops=1)
CTE cte
-> Unique (cost=519813.11..522319.10 rows=495358 width=1922) (actual time=2719.093..3523.029 rows=422638 loops=1)
-> Sort (cost=519813.11..521066.10 rows=501198 width=1922) (actual time=2719.091..3301.622 rows=423211 loops=1)
Sort Key: mytable.person_id, mytable.submission_date DESC NULLS LAST, mytable.last_updated DESC NULLS LAST, mytable.id DESC
Sort Method: external merge Disk: 152384kB
-> Seq Scan on mytable (cost=0.00..54367.63 rows=501198 width=1922) (actual time=293.953..468.554 rows=423211 loops=1)
Filter: (((status)::text = ANY ('{ACCEPTED,CORRECTED}'::text[])) AND (h_plan_id = ANY ('{1,2}'::bigint[])) AND ((type)::text <> 'CR'::text))
Rows Removed by Filter: 10158
-> Aggregate (cost=11145.56..11145.57 rows=1 width=8) (actual time=4142.116..4142.116 rows=1 loops=1)
-> CTE Scan on cte (cost=0.00..9907.16 rows=495358 width=0) (actual time=2719.095..4071.481 rows=422638 loops=1)
-> Limit (cost=20611.67..20611.69 rows=10 width=17084) (actual time=388.777..388.781 rows=10 loops=1)
-> Sort (cost=20611.67..21850.06 rows=495358 width=17084) (actual time=388.776..388.777 rows=10 loops=1)
Sort Key: cte_1.person_id
Sort Method: top-N heapsort Memory: 30kB
-> CTE Scan on cte cte_1 (cost=0.00..9907.16 rows=495358 width=17084) (actual time=0.013..128.314 rows=422638 loops=1)
Planning Time: 0.369 ms
JIT:
Functions: 9
Options: Inlining true, Optimization true, Expressions true, Deforming true
Timing: Generation 1.947 ms, Inlining 4.983 ms, Optimization 178.469 ms, Emission 110.261 ms, Total 295.660 ms
Execution Time: 4587.711 ms
您可以尝试简化查询：
SELECT DISTINCT ON (person_id) t.*
FROM my_table t
WHERE status in ('ACCEPTED', 'CORRECTED')
ORDER BY person_id, submission_date DESC, last_updated DESC, id DESC
我不确定 Postgres 是否足够聪明，可以在这种情况下使用 (person_id, submission_date DESC, last_updated DESC, id DESC, status) 上的索引，但值得一试。
您可以使用表达式上的索引来加快此过程：(status in ('ACCEPTED', 'CORRECTED'), person_id, submission_date DESC, last_updated DESC, id DESC).
编辑：
如果要按另一列排序，可以使用子查询：
SELECT t.*
FROM (SELECT DISTINCT ON (person_id) t.*
FROM my_table t
WHERE status in ('ACCEPTED', 'CORRECTED')
ORDER BY person_id, submission_date DESC, last_updated DESC, id DESC
) t
ORDER BY submission_date DESC
第一件事：你可以在同一查询中多次使用CTE的结果，这是主要的feature of CTEs.) 你所拥有的将像这样工作（同时仍然只使用一次 CTE）：
WITH cte AS (
SELECT * FROM (
SELECT *, row_number() -- see below
OVER (PARTITION BY person_id
ORDER BY submission_date DESC NULLS LAST -- see below
, last_updated DESC NULLS LAST -- see below
, id DESC) AS rn
FROM tbl
) sub
WHERE rn = 1
AND status IN ('ACCEPTED', 'CORRECTED')
)
SELECT *, count(*) OVER () AS total_rows_in_cte
FROM cte
LIMIT 10
OFFSET 0; -- see below
警告 1：rank()
rank() 可以 return 每个 person_id 和 rank = 1 多行。 DISTINCT ON (person_id)（如 Gordon 提供的那样）是 row_number() 的适用替代品 - 它适用于您，如附加信息所阐明的那样。参见：
- Select first row in each GROUP BY group?
警告 2：ORDER BY submission_date DESC
submission_date 和 last_updated 均未定义 NOT NULL。可能是 ORDER BY submission_date DESC, last_updated DESC ... 的问题请参阅：
- PostgreSQL sort by datetime asc, null first?
这些列真的应该是 NOT NULL 吗？
您回复了：
Yes, all those columns should be non-null. I can add that constraint. I put it as nullable since we get data in files which are not always perfect. But this is very rare condition and I can put in empty string instead.
类型 date 不允许空字符串。保持列可为空。 NULL 是这些情况下的正确值。按照说明使用 NULLS LAST 以避免 NULL 排在最前面。
警告 3：OFFSET
如果 OFFSET 等于或大于 CTE 编辑的行数 return，您将得到 无行，所以也没有总数。参见：
临时解决方案
解决到目前为止的所有注意事项，并根据添加的信息，我们可能会得出以下查询：
WITH cte AS (
SELECT DISTINCT ON (person_id) *
FROM tbl
WHERE status IN ('ACCEPTED', 'CORRECTED')
ORDER BY person_id, submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC
)
SELECT *
FROM (
TABLE cte
ORDER BY person_id -- ?? see below
LIMIT 10
OFFSET 0
) sub
RIGHT JOIN (SELECT count(*) FROM cte) c(total_rows_in_cte) ON true;
现在 CTE 实际上 使用了两次。 RIGHT JOIN 保证我们得到总数，不管 OFFSET。 DISTINCT ON 应该对基本查询中每个 (person_id) 仅有的几行执行 OK-ish。
但是你的行很宽。平均多宽？该查询可能会导致整个 table 的顺序扫描。索引不会帮助（很多）。所有这些对于分页 来说仍然非常低效 。参见：
您不能将索引用于分页，因为它基于从 CTE 派生的 table。而且您的分页实际排序标准仍然不清楚（ORDER BY id？）。如果分页是目标，那么您迫切需要一种不同的查询方式。如果您只对前几页感兴趣，则需要不同的查询样式。最佳解决方案取决于问题中仍然缺少的信息......
快得多
更新后的objective：
Find latest entries for a
person_idbysubmission_date
（为简单起见，忽略 "for specified filter criteria, type, plan, status"。）
并且：
Find the latest row per
person_idonly if that hasstatus IN ('ACCEPTED','CORRECTED')
基于这两个专门的指数:
CREATE INDEX ON tbl (submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC NULLS LAST)
WHERE status IN ('ACCEPTED', 'CORRECTED'); -- optional
CREATE INDEX ON tbl (person_id, submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC NULLS LAST);
运行 这个查询：
WITH RECURSIVE cte AS (
(
SELECT t -- whole row
FROM tbl t
WHERE status IN ('ACCEPTED', 'CORRECTED')
AND NOT EXISTS (SELECT FROM tbl
WHERE person_id = t.person_id
AND ( submission_date, last_updated, id)
> (t.submission_date, t.last_updated, t.id) -- row-wise comparison
)
ORDER BY submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC NULLS LAST
LIMIT 1
)
UNION ALL
SELECT (SELECT t1 -- whole row
FROM tbl t1
WHERE ( t1.submission_date, t1.last_updated, t1.id)
< ((t).submission_date,(t).last_updated,(t).id) -- row-wise comparison
AND t1.status IN ('ACCEPTED', 'CORRECTED')
AND NOT EXISTS (SELECT FROM tbl
WHERE person_id = t1.person_id
AND ( submission_date, last_updated, id)
> (t1.submission_date, t1.last_updated, t1.id) -- row-wise comparison
)
ORDER BY submission_date DESC NULLS LAST, last_updated DESC NULLS LAST, id DESC NULLS LAST
LIMIT 1)
FROM cte c
WHERE (t).id IS NOT NULL
)
SELECT (t).*
FROM cte
LIMIT 10
OFFSET 0;
这里的每一组括号都是必需的。
这种复杂程度应该通过使用给定的索引而不是顺序扫描来从根本上更快地检索一组相对较小的顶行。参见：
- Optimize GROUP BY query to retrieve latest row per user
submission_date 最有可能是类型 timestamptz 或 date，而不是 character varying(255)
- Refactor foreign key to fields
可能会优化更多细节，但这已经失控了。您可以考虑专业咨询。