Postgresql 使用索引对连接表进行排序

Posted 2023-02-16

【中文标题】Postgresql 使用索引对连接表进行排序

【英文标题】：Postgresql Sorting a Joined Table with an index

【发布时间】：2013-07-21 09:32:15

【问题描述】：

我目前正在处理 Postgres 9.2 中的一个复杂排序问题 您可以在此处找到此问题（简化）中使用的源代码：http://sqlfiddle.com/#!12/9857e/11

我有一个巨大的（>>20Mio 行）表，其中包含不同类型的各种列。

CREATE TABLE data_table
(
  id bigserial PRIMARY KEY,
  column_a character(1),
  column_b integer
  -- ~100 more columns
);

假设我想排序此表超过 2 列（ASC）。 但我不想通过简单的 Order By 来做到这一点，因为稍后我可能需要在排序的输出中 插入行，而用户可能只想一次看到 100 行（排序后的输出）。

为了实现这些目标，我做了以下工作：

CREATE TABLE meta_table
(
 id bigserial PRIMARY KEY,
 id_data bigint NOT NULL -- refers to the data_table
);

--Function to get the Column A of the current row
CREATE OR REPLACE FUNCTION get_column_a(bigint)
 RETURNS character AS
 'SELECT column_a FROM data_table WHERE id=$1'
 LANGUAGE sql IMMUTABLE STRICT;

--Function to get the Column B of the current row
CREATE OR REPLACE FUNCTION get_column_b(bigint)
 RETURNS integer AS
 'SELECT column_b FROM data_table WHERE id=$1'
 LANGUAGE sql IMMUTABLE STRICT;

--Creating a index on expression:
CREATE INDEX meta_sort_index
 ON meta_table
 USING btree
 (get_column_a(id_data), get_column_b(id_data), id_data);

然后我将 data_table 的 Id 复制到 meta_table：

INSERT INTO meta_table(id_data) (SELECT id FROM data_table);

稍后我可以通过类似的简单插入向表中添加其他行。 要获得第 900000 - 900099 行（100 行），我现在可以使用：

SELECT get_column_a(id_data), get_column_b(id_data), id_data 
FROM meta_table 
ORDER BY 1,2,3 OFFSET 900000 LIMIT 100;

（如果我想要所有数据，请在 data_table 上添加一个额外的 INNER JOIN。） 最终的计划是：

Limit (cost=498956.59..499012.03 rows=100 width=8)
-> Index Only Scan using meta_sort_index on meta_table (cost=0.00..554396.21 rows=1000000 width=8)

这是一个非常有效的计划（仅索引扫描是 Postgres 9.2 中的新功能）。 但是，如果我想获得 Rows 20'000'000 - 20'000'099（100 Rows）怎么办？相同的计划，更长的执行时间。好吧，为了提高偏移性能 (Improving OFFSET performance in PostgreSQL)，我可以执行以下操作（假设我将每 100'000 行保存到另一个表中）。

SELECT get_column_a(id_data), get_column_b(id_data), id_data 
FROM meta_table 
WHERE (get_column_a(id_data), get_column_b(id_data), id_data ) >= (get_column_a(587857), get_column_b(587857), 587857 )
ORDER BY 1,2,3 LIMIT 100;

这运行得更快。最终的计划是：

Limit (cost=0.51..61.13 rows=100 width=8)
-> Index Only Scan using meta_sort_index on meta_table (cost=0.51..193379.65 rows=318954 width=8)
Index Cond: (ROW((get_column_a(id_data)), (get_column_b(id_data)), id_data) >= ROW('Z'::bpchar, 27857, 587857))

到目前为止，一切都很完美，postgres 做得很好！

假设我想将第二列的顺序更改为 DESC。 但随后我将不得不更改我的 WHERE 子句，因为 > 运算符比较两个列 ASC。与上述相同的查询（ASC 排序）也可以写成：

SELECT get_column_a(id_data), get_column_b(id_data), id_data 
FROM meta_table 
WHERE 
   (get_column_a(id_data) > get_column_a(587857)) 
OR (get_column_a(id_data) = get_column_a(587857) AND ((get_column_b(id_data) > get_column_b(587857)) 
OR (                                                  (get_column_b(id_data) = get_column_b(587857)) AND (id_data >= 587857)))) 
ORDER BY 1,2,3 LIMIT 100;

现在计划发生变化，查询变慢：

Limit (cost=0.00..1095.94 rows=100 width=8)
-> Index Only Scan using meta_sort_index on meta_table (cost=0.00..1117877.41 rows=102002 width=8)
Filter: (((get_column_a(id_data)) > 'Z'::bpchar) OR (((get_column_a(id_data)) = 'Z'::bpchar) AND (((get_column_b(id_data)) > 27857) OR (((get_column_b(id_data)) = 27857) AND (id_data >= 587857)))))

如何通过 DESC-Ordering 使用高效的旧计划？ 你有什么更好的想法来解决这个问题吗？

（我已经尝试用自己的 Operator Classes 声明自己的 Type，但这太慢了）

【问题讨论】：

感谢***.com/questions/1677538/… 我尝试了UNIONS。比上一个Plan好一点，但还是不够。 sqlfiddle.com/#!12/9857e/28/3

【参考方案1】：

您需要重新考虑您的方法。从哪里开始？这是一个明显的例子，基本上是性能方面的限制，是您对 SQL 采用的那种功能方法。函数在很大程度上是计划程序不透明的，并且由于存储过程的计划不能折叠在一起，因此您在 data_table 上对检索到的每一行强制进行两次不同的查找。

现在，更糟糕的是，您正在根据另一个表中的数据索引一个表。这可能适用于仅附加的工作负载（允许插入但不允许更新），但如果 data_table 可以应用更新，它将不工作。如果 data_table 中的数据发生变化，您将让索引返回错误结果。

在这些情况下，几乎总是最好将连接写成显式的，并让计划者找出检索数据的最佳方法。

现在您的问题是，当您更改第二列的顺序时，您的索引变得不那么有用（并且磁盘 I/O 方面的密集程度更高）。另一方面，如果您在 data_table 上有两个不同的索引并且有一个显式连接，那么 PostgreSQL 可以更轻松地处理这个问题。