Por que as tarefas executadas por um usuário comum são mais lentas do que as executadas pelo usuário dbadmin?

Cenário 1: os usuários comuns estão sujeitos à gestão de recursos.

Enfileiramento de usuários comuns: waiting in queue/waiting in global queue/waiting in ccn queue

1. Os usuários comuns estarão aguardando na fila/aguardando na fila global quando o número de instruções ativas exceder o valor de max_active_statements. Enquanto os administradores não precisam enfileirar.

   Você pode aumentar o valor desse parâmetro ou limpar algumas declarações para evitar o enfileiramento.

   Altere o valor de max_active_statements no console de gerenciamento.

   1. Faça logon no console de gerenciamento do GaussDB(DWS).
   2. Na árvore de navegação à esquerda, escolha Clusters > Dedicated Clusters.
   3. Na lista de clusters, localize o cluster de destino e clique no nome do cluster. A página Basic Information é exibida.
   4. Vá para a página Parameter Modifications do cluster, procure o parâmetro max_active_statements, altere seu valor e clique em Save.
2. Demora muito tempo para que os usuários comuns aguardem na fila ccn. Quando o gerenciamento dinâmico de recursos está ativado(enable_dynamic_workload está definido como on), se a simultaneidade for alta e a memória disponível for pequena, os usuários comuns podem entrar nesse estado ao executar instruções. Os administradores não são controlados. Você pode parar algumas instruções ou aumentar o valor do parâmetro de memória. Se o uso de memória de cada DN não for alto, você poderá desativar o parâmetro de gerenciamento dinâmico de recursos enable_dynamic_workload definindo-o como off.

Cenário 2: a condição OR no plano de execução verifica as instruções executadas por usuários comuns, uma a uma. Isso consome muito tempo.

As condições OR nos planos de execução contêm verificações relacionadas à permissão. Esse cenário geralmente ocorre quando o modo de exibição do sistema é usado. Por exemplo, na seguinte instrução 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 do plano de execução é a seguinte:

Na exibição do sistema, a condição OR é usada para verificação de permissão.

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 é sempre retornado para pg_has_role do uso de dbadmin. Portanto, as condições após OR não precisam ser verificadas.

Enquanto as condições OR de um usuário comum precisam ser verificadas uma por uma. Se houver um grande número de tabelas no banco de dados, o tempo de execução do usuário comum é maior que o do usuário dbadmin.

Nesse cenário, se o número de conjuntos de resultados de saída for pequeno, você poderá definir set enable_hashjoin e enable_seqscan como off, para usar o plano index+nestloop.

Cenário 3: os pools de recursos alocados para usuários comuns e administradores são diferentes.

Execute o comando a seguir para verificar se os pools de recursos correspondentes a um usuário comum são os mesmos do usuário administrador. Se eles forem diferentes, verifique se os recursos do locatário alocados aos dois usuários são diferentes.

1

SELECt * FROM pg_user;