PostgREST升级后RLS查询性能下降问题分析

PostgREST是一个流行的PostgreSQL REST API框架，最近有用户报告从v10升级到v12版本后，行级安全(RLS)查询性能显著下降。本文将深入分析这一问题的根本原因，并提供优化建议。

问题现象

用户在升级PostgREST后，发现原本200ms的查询延长到了1.3秒。具体表现为：

1. 对jsonb字段的PATCH操作变慢
2. GET请求同样受到影响
3. 使用服务角色(bypass RLS)时性能正常
4. 相同查询在v10和v12版本执行计划相同，但实际执行时间差异显著

根本原因分析

经过深入调查，发现性能下降主要有两个关键因素：

1. JWT声明获取方式变更

PostgREST v12移除了request.jwt.claim.sub风格的JWT声明访问方式。这导致用户自定义的auth.uid()函数需要做更多工作：

CREATE FUNCTION auth.uid() RETURNS uuid
    LANGUAGE sql STABLE
    AS $$
  select 
  	coalesce(
		nullif(current_setting('request.jwt.claim.sub', true), ''),
		(nullif(current_setting('request.jwt.claims', true), '')::jsonb ->> 'sub')
	)::uuid
$$;

在v12中，由于第一种方式返回NULL，函数必须每次都解析整个JWT声明对象，显著增加了开销。

2. RLS策略实现方式不佳

用户的RLS策略实现方式导致性能问题：

CREATE POLICY "User can all their own and team page_versions" 
ON public.page_versions 
USING ((site_id IN (SELECT page_ids_by_user.page_ids_by_user 
                    FROM public.page_ids_by_user() page_ids_by_user(page_ids_by_user))));

这种写法会导致page_ids_by_user()函数为表中的每一行都执行一次，而不是只执行一次。

优化建议

1. 修改RLS策略实现

将RLS策略改为以下形式：

CREATE POLICY "User can all their own and team page_versions" 
ON public.page_versions 
USING ((site_id IN ((SELECT page_ids_by_user.page_ids_by_user 
                     FROM public.page_ids_by_user() page_ids_by_user(page_ids_by_user)))));

关键区别在于添加了额外的括号，这使得PostgreSQL可以将子查询提取为InitPlan节点，只需执行一次。

2. 考虑JWT声明处理优化

虽然PostgREST v12的变更是为了兼容PostgreSQL 14+，但可以考虑：

1. 缓存JWT声明解析结果
2. 简化auth.uid()函数的实现
3. 在应用层预先解析JWT并作为参数传递

结论

PostgREST升级导致的性能问题通常是多因素共同作用的结果。通过优化RLS策略实现方式和理解框架内部变更对自定义函数的影响，可以有效恢复甚至提升性能。建议开发者在升级前充分测试关键查询性能，并参考官方文档了解重大变更。