为什么普通用户比dbadmin用户执行的慢？

场景一：普通用户受资源管理的管控

普通用户在排队：waiting in queue/waiting in global queue/waiting in ccn queue.

1. 普通用户主要在waiting in queue/waiting in global queue时。

   当前的活跃语句数超过max_active_statements限制导致的普通用户排队，由于管理员用户不受管控所以无需排队。可通过在管理控制台修改max_active_statements参数值处理：

   1. 登录GaussDB(DWS)管理控制台。
   2. 在左侧导航树，单击“集群 > 专属集群 ”。
   3. 在集群列表中找到所需要的集群，然后单击集群名称。
   4. 进入集群的“参数修改”页面，搜索“max_active_statements”参数，修改其参数值，单击“保存”，确认无误后再单击“保存”。
2. 普通用户在waiting in ccn queue比较耗时。

   动态资源管理打开的情况下（enable_dynamic_workload = on），如果此时并发较高，可用内存比较少，普通用户执行语句时会进入该状态，管理员用户不受管控。可通过终止一部分语句或调大内存参数规避，如果各DN的内存使用都不高，也可考虑关闭动态资源管理enable_dynamic_workload（enable_dynamic_workload = off）。

场景二：执行计划中的or条件对普通用户执行语句逐一判断耗时

执行计划中的or条件里有权限相关的判断，此场景多发生在使用系统视图时。例如以下sql：

1
2
3
4
5
6
7
8

SELECT distinct(dtp.table_name),
 ta.table_catalog,
 ta.table_schema,
 ta.table_name,
 ta.table_type  
from information_schema.tables ta left outer join DBA_TAB_PARTITIONS dtp  
on (dtp.schema = ta.table_schema and dtp.table_name = ta.table_name) 
where ta.table_schema = 'public';

一部分执行计划如下：

可以看到系统视图中的权限判断中多用or条件判断：

1

pg_has_role(c.relowner, 'USAGE'::text) OR has_table_privilege(c.oid, 'SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER'::text) OR has_any_column_privilege(c.oid, 'SELECT, INSERT, UPDATE, REFERENCES'::text)

由于dbadmin用户pg_has_role总能返回true，因此or之后的条件无需继续判断；

而普通用户的or条件需要逐一判断，如果数据库中表个数比较多，最终会导致普通用户比dbadmin需要更长的执行时间。

这种场景如果输出结果集很少，可以考虑尝试设置set enable_hashjoin = off; set enable_seqscan = off; 走index + nestloop的计划。

场景三：普通用户和管理员用户所分配资源池有差异

通过执行如下查询命令，查看用户所对应的资源池是否相同，如果不同，可在界面查看两个资源池上所分配的租户资源是否有差别。

1

SELECt * FROM pg_user;