¿Por qué las tareas ejecutadas por un usuario ordinario son más lentas que las ejecutadas por el usuario dbadmin?

Escenario 1: Los usuarios ordinarios están sujetos a la gestión de recursos.

Usuarios ordinarios en cola: waiting in queue/waiting in global queue/waiting in ccn queue

1. Los usuarios ordinarios serán waiting in queue/waiting in global queue cuando el número de sentencias activas exceda el valor de max_active_statements. Mientras que los administradores no necesitan cola.

   Puede aumentar el valor de este parámetro o borrar algunas instrucciones para evitar la cola.

   Cambie el valor de max_active_statements en la consola de gestión.

   1. Inicie sesión en la consola de gestión de GaussDB(DWS).
   2. En el árbol de navegación de la izquierda, haga clic en Clusters.
   3. En la lista de clústeres, busque el clúster objetivo y haga clic en el nombre del clúster. Se muestra Basic Information.
   4. Vaya a la página Parameter Modifications del clúster, busque el parámetro max_active_statements, cambie su valor y haga clic en Save.
2. Se necesita mucho tiempo para que los usuarios ordinarios esperen en la cola ccn. Cuando se habilita la gestión dinámica de recursos (enable_dynamic_workload se establece en on), si la simultaneidad es alta y la memoria disponible es pequeña, los usuarios comunes pueden entrar en este estado al ejecutar instrucciones. Los administradores no están controlados. Puede detener algunas instrucciones o aumentar el valor del parámetro de memoria. Si el uso de memoria de cada DN no es alto, puede deshabilitar el parámetro de gestión dinámica de recursos enable_dynamic_workload definiéndolo en off.

Escenario 2: La condición OR en el plan de ejecución comprueba las sentencias ejecutadas por los usuarios comunes una por una. Esto consume mucho tiempo.

Las condiciones OR de los planes de ejecución contienen comprobaciones relacionadas con los permisos. Este escenario suele ocurrir cuando se utiliza la vista del sistema. Por ejemplo, en la siguiente instrucción de 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';

Parte del plan de ejecución es el siguiente:

En la vista de sistema, se utiliza la condición OR para la comprobación de permisos.

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)

true siempre se devuelve para pg_has_role del uso dbadmin. Por lo tanto, no es necesario comprobar las condiciones después del OR.

Mientras que las condiciones OR de un usuario ordinario necesitan ser comprobadas una por una. Si hay un gran número de tablas en la base de datos, el tiempo de ejecución del usuario ordinario es más largo que el del usuario dbadmin.

En este escenario, si el número de conjuntos de resultados de salida es pequeño, puede establecer set enable_hashjoin y enable_seqscan en off para usar el plan index+nestloop.

Escenario 3: Los grupos de recursos asignados a los usuarios y administradores ordinarios son diferentes.

Ejecute el siguiente comando para comprobar si los grupos de recursos correspondientes a un usuario ordinario son los mismos que los del usuario administrador. Si son diferentes, compruebe si los recursos del tenant asignados a los dos usuarios son diferentes.

1

select * from pg_user;