为什么postgresql planner不在存储函数中使用索引扫描而不是显式排序？
我有一个函数，它使用ORDERBY子句执行查询。当我调用这个函数时，postgres会被卡住，但是当我使用传递给函数的值执行查询时，它会立即响应。 该函数如下所示：为什么postgresql planner不在存储函数中使用索引扫描而不是显式排序？,sql,database,postgresql,optimization,sql-execution-plan,Sql,Database,Postgresql,Optimization,Sql Execution Plan,我有一个函数，它使用ORDERBY子句执行查询。当我调用这个函数时，postgres会被卡住，但是当我使用传递给函数的值执行查询时，它会立即响应。 该函数如下所示： CREATE OR REPLACE FUNCTION get_all_synset_tags_by_name( lim int, offs int ) RETURNS SETOF ctags AS $$ SELECT concepts.id, expressions.name,
CREATE OR REPLACE FUNCTION get_all_synset_tags_by_name(
lim int,
offs int
) RETURNS SETOF ctags AS $$
SELECT concepts.id, expressions.name,
array_to_string(
array(
SELECT descr FROM ctags WHERE id IN (SELECT unnest(
concept_get_expr_synonyms(concepts.id)
))),'; '
), (
SELECT sum(freq) FROM ctags WHERE id IN (SELECT unnest(
concept_get_expr_synonyms(concepts.id)
)))::integer
FROM concepts,expressions
WHERE
concepts.is_dropped=FALSE AND expressions.is_dropped=FALSE AND expressions.id=concepts.expr_id AND
concepts.id=(concept_get_expr_synonyms(concepts.id))[1]
ORDER BY name
LIMIT $1 OFFSET $2;
$$ language sql STABLE;
CREATE OR REPLACE FUNCTION get_top_tags_all_name(
user_id int,
lim int,
offs int,
at bool,
dt bool,
mt bool
)
RETURNS
TABLE(
id int,
name text,
descr text,
freq int,
foll_status bool,
ad_perm bool,
rm_perm bool,
ed_perm bool,
n_folls bigint,
n_quests bigint,
n_opins bigint
) AS $$
SELECT ctags.id,ctags.name,ctags.descr,ctags.freq,
(SELECT users_tags.is_ignored
FROM users_tags
WHERE users_tags.tag=ctags.id AND users_tags.follower=$1),
$4,$5,$6,
(SELECT count(tag) FROM users_tags
WHERE users_tags.tag=ctags.id AND users_tags.is_ignored=FALSE),
(SELECT count(question_tags.question_id) FROM question_tags
LEFT JOIN questions ON question_tags.question_id=questions.id
WHERE question_tags.tag_id=ctags.id AND questions.qtype='quest' ),
(SELECT count(question_tags.question_id) FROM question_tags
LEFT JOIN questions ON question_tags.question_id=questions.id
WHERE question_tags.tag_id=ctags.id AND questions.qtype='opin' )
FROM get_all_synset_tags_by_name($2,$3) AS ctags;
$$ language sql STRICT;
qa=# EXPLAIN SELECT ctags.id,ctags.name,ctags.descr,ctags.freq,
qa-# (SELECT users_tags.is_ignored
qa(# FROM users_tags
qa(# WHERE users_tags.tag=ctags.id AND users_tags.follower=1),
qa-# FALSE,FALSE,FALSE,
qa-# (SELECT count(tag) FROM users_tags
qa(# WHERE users_tags.tag=ctags.id AND users_tags.is_ignored=FALSE),
qa-# (SELECT count(question_tags.question_id) FROM question_tags
qa(# LEFT JOIN questions ON question_tags.question_id=questions.id
qa(# WHERE question_tags.tag_id=ctags.id AND questions.qtype='quest' ),
qa-# (SELECT count(question_tags.question_id) FROM question_tags
qa(# LEFT JOIN questions ON question_tags.question_id=questions.id
qa(# WHERE question_tags.tag_id=ctags.id AND questions.qtype='opin' )
qa-# FROM get_all_synset_tags_by_name(10,0) AS ctags;
QUERY PLAN
----------------------------------------------------------------------------------------------------------------------------------------------
Subquery Scan ctags (cost=0.00..21323.00 rows=10 width=72)
-> Limit (cost=0.00..20434.38 rows=10 width=36)
-> Nested Loop (cost=0.00..19645616.99 rows=9614 width=36)
-> Index Scan using expressions_name_key on expressions (cost=0.00..996449.61 rows=1504967 width=36)
Filter: (NOT is_dropped)
-> Index Scan using concepts_expr_id_idx on concepts (cost=0.00..12.08 rows=1 width=8)
Index Cond: (public.concepts.expr_id = public.expressions.id)
Filter: ((NOT public.concepts.is_dropped) AND (public.concepts.id = (concept_get_expr_synonyms(public.concepts.id))[1]))
SubPlan 5
-> Nested Loop (cost=0.28..23.65 rows=1 width=43)
-> Nested Loop (cost=0.28..17.63 rows=1 width=47)
-> Nested Loop (cost=0.28..8.96 rows=1 width=8)
-> HashAggregate (cost=0.28..0.29 rows=1 width=4)
-> Result (cost=0.00..0.26 rows=1 width=0)
-> Index Scan using tags_conc_id_key on tags (cost=0.00..8.66 rows=1 width=4)
Index Cond: (public.tags.conc_id = (unnest(concept_get_expr_synonyms($1))))
-> Index Scan using concepts_id_key1 on concepts (cost=0.00..8.66 rows=1 width=51)
Index Cond: (public.concepts.id = public.tags.conc_id)
-> Index Scan using expressions_pkey on expressions (cost=0.00..6.01 rows=1 width=4)
Index Cond: (public.expressions.id = public.concepts.expr_id)
SubPlan 6
-> Aggregate (cost=23.66..23.67 rows=1 width=4)
-> Nested Loop (cost=0.28..23.65 rows=1 width=4)
-> Nested Loop (cost=0.28..17.63 rows=1 width=8)
-> Nested Loop (cost=0.28..8.96 rows=1 width=12)
-> HashAggregate (cost=0.28..0.29 rows=1 width=4)
-> Result (cost=0.00..0.26 rows=1 width=0)
-> Index Scan using tags_conc_id_key on tags (cost=0.00..8.66 rows=1 width=8)
Index Cond: (public.tags.conc_id = (unnest(concept_get_expr_synonyms($1))))
-> Index Scan using concepts_id_key1 on concepts (cost=0.00..8.66 rows=1 width=8)
Index Cond: (public.concepts.id = public.tags.conc_id)
-> Index Scan using expressions_pkey on expressions (cost=0.00..6.01 rows=1 width=4)
Index Cond: (public.expressions.id = public.concepts.expr_id)
SubPlan 1
-> Index Scan using users_tags_tag_key on users_tags (cost=0.00..8.27 rows=1 width=1)
Index Cond: ((tag = $0) AND (follower = 1))
SubPlan 2
-> Aggregate (cost=14.90..14.91 rows=1 width=4)
-> Bitmap Heap Scan on users_tags (cost=4.33..14.88 rows=5 width=4)
Recheck Cond: (tag = $0)
Filter: (NOT is_ignored)
-> Bitmap Index Scan on users_tags_tag_key (cost=0.00..4.33 rows=10 width=0)
Index Cond: (tag = $0)
SubPlan 3
-> Aggregate (cost=32.83..32.84 rows=1 width=4)
-> Nested Loop (cost=0.00..32.82 rows=2 width=4)
-> Seq Scan on questions (cost=0.00..16.25 rows=2 width=4)
Filter: (qtype = 'quest'::quest_type)
-> Index Scan using question_tags_question_id_key on question_tags (cost=0.00..8.27 rows=1 width=4)
Index Cond: ((public.question_tags.question_id = public.questions.id) AND (public.question_tags.tag_id = $0))
SubPlan 4
-> Aggregate (cost=32.83..32.84 rows=1 width=4)
-> Nested Loop (cost=0.00..32.82 rows=2 width=4)
-> Seq Scan on questions (cost=0.00..16.25 rows=2 width=4)
Filter: (qtype = 'opin'::quest_type)
-> Index Scan using question_tags_question_id_key on question_tags (cost=0.00..8.27 rows=1 width=4)
Index Cond: ((public.question_tags.question_id = public.questions.id) AND (public.question_tags.tag_id = $0))
(57 rows)
SELECT * FROM get_top_tags_all_name(1,10,0,FALSE,FALSE,FALSE);
^CCancel request sent
ERROR: canceling statement due to user request
CONTEXT: PL/pgSQL function "concept_get_expr_synonyms" line 6 at assignment
SQL function "get_top_tags_all_name" statement 1
所以我认为查询计划器当时并不依赖于索引。如果有任何帮助，我们将不胜感激。我认为问题在于，PG为该功能制定了查询计划，而统计数据还不足以进行优化。假设您的函数实际上只是一行SELECT语句，那么使用模糊的
PREPAREEXECUTESET enable_sort=FALSE;
默认情况下，postgresql尝试通过显式排序数据来优化小表上的大索引扫描。如果表很小，并且需要大部分数据，那么显式排序比索引扫描快。问题是，在我的例子中，表是巨大的，需要一小部分数据，但postgresql在准备函数时并不知道这一点。如果您只发布一点代码，它可能会被绑定到一本书中！我发布了这么多代码，只是希望它能有所帮助。尽量少发布仍然显示问题的代码，所以您可以提供一个解决方案。帮助您的人不应该（通常也不会）费力地阅读大量的代码-帮助他们帮助您。您还可以尝试更改此类操作的成本，使其更适合您的硬件配置：