我SELECT在使用<运算符时速度非常慢 我正在寻找修复或解决方法来执行此操作：
EXPLAIN (ANALYZE)
SELECT *
FROM "users"
WHERE (engagement_level(social) < 1)
AND (social_peemv(social) < 33.333333333333336)
AND (array['United Kingdom'] <@ mixed_frequent_locations(location))
AND (is_visible(social, flags) = TRUE)
ORDER BY "users"."created_at" ASC
LIMIT 12 OFFSET 0;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- ---------------------------
Limit (cost=0.43..18572.10 rows=12 width=860) (actual time=5658.037..175582.743 rows=12 loops=1)
-> Index Scan using created_at_idx on users (cost=0.43..6244724.16 rows=4035 width=860) (actual time=5658.035..175582.735 rows=12 loops=1)
Filter: (is_visible(social, flags) AND (engagement_level(social) < 1) AND (social_peemv(social) < '33.3333333333333'::double precision) AND ('{"United Kingdom"}'::text[] <@ mixed_frequent_locations(location)))
Rows Removed by Filter: 2816798
Planning time: 1.573 ms
Execution time: 175583.373 ms
(6 rows)
EXPLAIN (ANALYZE)
SELECT *
FROM "users"
WHERE (engagement_level(social) < 1)
AND (social_peemv(social) = 33.3333)
AND (array['United Kingdom'] <@ mixed_frequent_locations(location))
AND (is_visible(social, flags) = TRUE)
ORDER BY "users"."created_at" ASC
LIMIT 12 OFFSET 0;
QUERY PLAN
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Limit (cost=380.04..380.31 rows=1 width=863) (actual time=0.051..0.051 rows=0 loops=1)
-> Result (cost=380.04..380.31 rows=1 width=863) (actual time=0.050..0.050 rows=0 loops=1)
-> Sort (cost=380.04..380.05 rows=1 width=896) (actual time=0.049..0.049 rows=0 loops=1)
Sort Key: created_at
Sort Method: quicksort Memory: 25kB
-> Index Scan using idx_in_social_peemv on users (cost=0.43..380.03 rows=1 width=896) (actual time=0.044..0.044 rows=0 loops=1)
Index Cond: (social_peemv(social) = '33.3333'::double precision)
Filter: (is_visible(social, flags) AND (engagement_level(social) < 1) AND ('{"United Kingdom"}'::text[] <@ mixed_frequent_locations(location)))
Planning time: 0.459 ms
Execution time: 0.095 ms
在第一种情况下，没有Index Cond应用并且执行时间增长到175583.373 ms
指数：
CREATE INDEX idx_in_social_peemv ON users USING BTREE ( social_peemv(social) ) ;
CREATE INDEX mixed_frequent_locations_idx on users USING GIN ( mixed_frequent_locations(location) ) ;
CREATE INDEX created_at_idx ON users USING btree (created_at)
CREATE INDEX idx_in_social_follower_count_and_created_at ON users USING btree (social_follower_count(social) DESC, created_at)
CREATE INDEX idx_in_egagagement_level_and_created_at ON users USING btree (engagement_level(social), creat
ed_at)
桌子：
CREATE TABLE users (
id SERIAL PRIMARY KEY NOT NULL,
name TEXT,
bio TEXT,
social jsonb,
flags array,
location jsonb,
search_field ts_vector,
created_at TIMESTAMP WITHOUT TIMEZONE,
udpated_at TIMESTAMP WITHOUT TIMEZONE
);
Postgres 版本：10
整个条件匹配 20 条记录，共 3669284 条
每个条件匹配：
(engagement_level(social) < 1)= 801176
(social_peemv(social) < 33.333333333333336)= 1621516
(array['United Kingdom'] <@ mixed_frequent_locations(location))= 91625
(is_visible(social, flags) = TRUE)= 3333733
正如@jjanes 所建议的，我尝试删除LIMITandOFFSET并且查询计划更改为位图堆扫描：
EXPLAIN (ANALYZE)
SELECT *
FROM "users"
WHERE (engagement_level(social) < 1)
AND (social_peemv(social) < 33.333333333333336)
AND (array['United Kingdom'] <@ mixed_frequent_locations(location))
AND (is_visible(social, flags) = TRUE)
ORDER BY "users"."created_at" ASC;
QUERY PLAN
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Sort (cost=77641.99..77652.36 rows=4148 width=1393) (actual time=1195.544..1195.546 rows=20 loops=1)
Sort Key: created_at
Sort Method: quicksort Memory: 59kB
-> Bitmap Heap Scan on users (cost=18046.48..77392.73 rows=4148 width=1393) (actual time=227.471..1195.481 rows=20 loops=1)
Recheck Cond: (('{"United Kingdom"}'::text[] <@ mixed_frequent_locations(location)) AND (engagement_level(social) < 1))
Filter: (is_visible(social, flags) AND (social_peemv(social) < '33.3333333333333'::double precision))
Rows Removed by Filter: 19444
Heap Blocks: exact=19238
-> BitmapAnd (cost=18046.48..18046.48 rows=28415 width=0) (actual time=218.484..218.484 rows=0 loops=1)
-> Bitmap Index Scan on mixed_frequent_locations_idx (cost=0.00..1356.36 rows=128634 width=0) (actual time=44.794..44.794 rows=108076 loops=1)
Index Cond: ('{"United Kingdom"}'::text[] <@ mixed_frequent_locations(location))
-> Bitmap Index Scan on idx_in_egagagement_level_and_created_at (cost=0.00..16687.80 rows=1156662 width=0) (actual time=163.368..163.368 rows=801189 loops=1)
Index Cond: (engagement_level(social) < 1)
Planning time: 3.326 ms
Execution time: 1197.242 ms
除 之外的所有应用条件is_visible均由用户提供
您有一个典型的列依赖问题。PostgreSQL 估计会有 4035 行满足 WHERE 子句。如果我采用您报告的实际选择性并将它们相乘（只有当每个选择性独立于其他选择性时才是正确的），我得到 8032 行。但真正的价值是 20。显然英国人异常不合群，或者类似的东西。
对于 LIMIT 12，它认为它只会按照与 ORDER BY 相同的顺序遍历索引，并在找到 12 行通过过滤器后停止。它认为它只需要走指数的 12/4035 左右。但它确实需要走指数的 12/20 左右（除非创建日期和社交性之间也存在相关性，否则即使这些估计也是错误的）。所以它选择这些方法是因为它认为它们会更快。
在较新版本的 PostgreSQL 中，您可以收集有关列间依赖性的统计信息，但您不能对函数/表达式执行此操作，因此它对您不起作用。无论如何，我认为它不适用于数组列。
如果您的截止值是硬编码的，您可以创建如下所示的部分索引，但听起来这对您也不起作用，除非您愿意对此做出妥协。
您通常可以通过使用正确的列顺序制作多列索引来解决该问题，这对查询非常有用，即使选择性估计有很大偏差，它也会被使用。但是由于所有选择条件都基于不等式或数组成员资格，因此如何得出这样的索引并不明显。您可以为此使用 GiST 索引。
btree_gist为数字上的 '<' 提供 GiST 运算符类，但我不知道任何提供 <@ 字符串数组支持的东西。您可以尝试使用索引USING GIST ON (engagement_level(social), social_peemv(social))，但由于您的大部分选择性来自于mixed_frequent_locations(location)我，我不会寄予厚望，即没有索引的索引会运行得足够好，看起来比现有的索引 ORDER BY 计划更好。将它们放在一起，我认为您在这里没有很多不错的选择。有选择地寻找问题查询并删除它们的 LIMIT 可能是最好的选择，尽管它可能并不漂亮。您可以像这样指定 ORDER BY，而不是删除 LIMIT：
它将防止使用具有虚假吸引力的索引，而不会更改查询的输出。
在快速查询中，您将返回 0 行。这很容易。PostgreSQL 看到
social_peemv(social)并有一个多汁的统计估计和扫描idx_in_social_peemv。它返回 0 行，查询完成。在另一个你说的
< 33.333333333333336。由于这意味着将近一半的表，PostgreSQL 发现根据选择性估计，该值不值得付出代价。相反，它扫描不同的索引，然后从其结果集中删除 2816798 行。我们仍然不知道你的函数在做什么，我们也没有表定义。你也没有给我们所有的索引
created_at_idx。