Por enquanto, nosso SQL Server de produção é Standard_D96ds_v5uma máquina Azure VM.
Recebemos uma solicitação para verificar se podemos reduzir o tamanho do servidor para Standard_D48ds_v5.
Que medidas tomaremos em consideração para termos a confirmação de que podemos reduzir o tamanho do servidor?
Adoro usar CTEs para criar consultas claras e agradáveis. No entanto, tenho certeza de que a consulta que criei é realmente ineficiente.
Existe uma maneira melhor de fazer isso e manter as coisas claras?
with first_date as (
-- selecting just 1 date
-- namely: 1 full year ago
select (extract(year from current_date - interval '1 year')||'-01-01' )::date as date
)
, last_date as (
select date from star.dim_date where current_cal_day='Current'
)
, total_active_customers_ps_day as(
select
dd.date
, dd.is_first_day_in_month
, dd.is_last_day_in_month
, count(dc.id) as total_customers
from first_date, last_date,
star.dim_date dd
-- join with dim_client, using first_subscription_start_date & last_subscription_end_date
-- to get the ids of just the active clients
join star.dim_client dc on dd.date
between dc.first_subscription_start_date and coalesce(dc.last_subscription_end_date::date, '3000-01-01')
and dc.created <= dd.date
and dc.first_subscription_start_date >= dc.created::date
where
dd.date >= first_date.date
and dd.date <= last_date.date
group by
dd.date
, dd.is_first_day_in_month
, dd.is_last_day_in_month
)
select * from total_active_customers_ps_day ;
Acho que estou causando algumas junções cartesianas, já que essa consulta é bem mais eficiente
with total_active_customers_ps_day as(
select
dd.date
, dd.is_first_day_in_month
, dd.is_last_day_in_month
, count(dc.id) as total_customers
from
star.dim_date dd
-- join with dim_client, using first_subscription_start_date & last_subscription_end_date
-- to get the ids of just the active clients
join star.dim_client dc on dd.date
between dc.first_subscription_start_date and coalesce(dc.last_subscription_end_date::date, '3000-01-01')
and dc.created <= dd.date
and dc.first_subscription_start_date >= dc.created::date
where
dd.date >= (extract(year from current_date - interval '1 year')||'-01-01' )::date
and dd.date <= (select date from star.dim_date where current_cal_day='Current')
group by
dd.date
, dd.is_first_day_in_month
, dd.is_last_day_in_month
)
select * from total_active_customers_ps_day ;
Qual é a melhor maneira de fazer isso?
Entendo que, para obter uma lista de clusters, pg_lsclusterpreciso usar ferramentas como pg_createcluster.
Mas eu uso initdbe pg_ctlpara criar clusters. Eu sei que eles estão em execução porque posso acessar cada cluster (tenho três clusters) com arquivos psql -p [port].
Como obtenho uma lista de clusters criados com essas ferramentas?
Estou construindo um aplicativo que requer muitas tabelas em um banco de dados e, embora a união e agregação de dados sejam realmente agradáveis e contínuas, estou começando a me perguntar se estou criando muitas tabelas em um banco de dados em vez de organizar melhor criando vários bancos de dados.
Qualquer ajuda ou orientação ajudaria,
Já vi muitas perguntas sobre alguém tentando conceder uma role_specification a algum other_role , mas recebendo o GRANTerro
ERROR: must have admin option on rolerole_specification
e todas as respostas, de uma forma ou de outra, parecem resumir-se a "Isso está acontecendo porque o WITH ADMINnão foi usado quando o original foi emitido."GRANTroleTOrole_specification...
Então agora eu não posso fazer GRANTrole_specificationTOother_role
Mas o que me surpreendeu é que não consigo encontrar nada sobre como realmente ver se a opção admin está definida para uma função. Respostas como Liste os privilégios do banco de dados usando o psql revelam privilégios para funções, mas nenhum desses atributos parece corresponder ao arquivo admin option. A documentação do Postgres também parece muda sobre isso.
Então... onde o Postgres controla isso e como posso consultá-lo?
Com base na resposta de @Erwin Brandstetter, tenho algumas perguntas mais profundas...
SELECT roleid::regrole, member::regrole, grantor::regrole, admin_option
FROM pg_auth_members where roleid::regrole::text like 'content%';;
roleid | member | grantor | admin_option
---------------+---------------+---------------+--------------
content_adm | int_web_admin | content_adm | f
content_rwd | randall | postgres | f
content_rwd | content_adm | postgres | f
Todos os roleids têm as admin_optionfalse em todas as linhas da tabela pg_auth_members (mas um postgresroleid notavelmente não estava lá). Mesmo assim, content_adm pode conceder content_adm à função int_web_admin, mas não pode conceder content_rwd a ela.
As linhas relevantes do \dushow:
Role name | Attributes | Member of
------------------+----------------+----------------------------------
content_adm | | {content_rwd}
content_rwd | Cannot login | {}
randall | | {content_rwd}
int_web_admin | | {sys_role,content_adm}
(Acredito que a associação content_adm e randall de content_rwd foi configurada pelo DBA anterior)
Portanto, minha segunda pergunta complementar é: Como traduzo o resultado da consulta SQL em informações semelhantes às \drg?
Minha pergunta básica é: o que afeta o desempenho de \d?
Eu tenho um esquema separado (pequeno) que gerencio em um servidor de banco de dados no qual não tenho privilégios superiores. O servidor contém um enorme banco de dados (mais de bilhões de linhas) em seu esquema público. Meu esquema separado fornece algumas informações auxiliares usadas apenas para renderização de dados na página da Web no esquema público.
Editar : na verdade, são mais de 5,5 bilhões de linhas, e isso está apenas em uma das maiores tabelas (e levou apenas 1,5 horas para terminar count(*)!).
Quando faço um simples \dno prompt do psql, é muito lento - da ordem de 6,5 segundos quando cronometro. Claramente, o banco de dados/servidor de banco de dados tem carga pesada, mas devo levar esse \ddesempenho à atenção dos administradores de sistemas (que geralmente não querem ser incomodados)? (Isso implica algo marcadamente errado no sistema?) Todo o resto no meu esquema é executado na ordem de milissegundos, portanto, não afeta o desempenho do meu esquema em si .
Independentemente de eu chamar a atenção deles, o que impacta o desempenho de \d? O esquema público possui 985 tabelas. Mesmo assim, parece que seria uma consulta bastante simples; Eu esperaria que estivesse apenas olhando os nomes das tabelas, não o conteúdo das tabelas.
Tenho uma metricstabela particionada por ano e mês ( metrics_y2023m01, metrics_y2023m02, etc). O analyze metricscomando atualiza as estatísticas da tabela e de cada partição individualmente, mas a grande maioria das modificações ocorre na partição do mês atual, então pensei em espaçar no tempo a execução da análise de toda a tabela e agendar outra diária análise da partição mais ocupada.
Obrigado.
Estou enfrentando um problema com o desempenho da consulta do SQL Server e espero obter alguns insights de todos vocês.
Declaração do problema:
Eu tenho uma consulta SQL que funciona bem (~6 ms) quando executada diretamente no SQL Server Management Studio (SSMS), mostrando uma "Busca de índice" no plano de execução. No entanto, quando a mesma consulta é executada em meu aplicativo Java usando JDBC, o plano de execução mostra uma "Varredura de índice" e a consulta leva muito mais tempo (~ 1 segundo) para ser executada.
O que eu tentei:
Pergunta:
Planeje quando isso será executado em Java: https://www.brentozar.com/pastetheplan/?id=SkWWezsya
Planeje quando isso será executado a partir do SSMS: https://www.brentozar.com/pastetheplan/?id=HJZPefokp
Quaisquer ideias ou sugestões serão muito apreciadas.
De acordo com este link, para realizar algo paralelo na extensão postgresql, multi-thread não é uma opção.
Então, existe algum outro método? Como alguma API e uso sobre multiprocessos? Talvez me diga onde posso encontrar algum código de exemplo?
Ou a própria expectativa de realizar algo paralelo na extensão Postgresql não é nada razoável? Você poderia fornecer alguma explicação?
Atualizado: Em relação às coisas que quero paralelizar, geralmente não tem nada com o Postgresql, mas calcula o hash de um monte de dados
A integridade referencial de FOREIGN KEYs no PostgreSQL pode ser desabilitada executando:
ALTER TABLE schema.my_table
DISABLE TRIGGER ALL;
Mas infelizmente o comando também desabilitará todos os outros triggers presentes na tabela.
Tentei localizar o nome da chave estrangeira à pg_constraintvista, mas usá-lo no seguinte comando retorna um erro:
ALTER TABLE schema.my_table
DISABLE TRIGGER id_fkey;
-- Returns
-- SQL Error [42704]: ERROR: trigger "id_fkey" for table "my_table" does not exist
Como a integridade referencial pode ser desabilitada no PostgreSQL sem desabilitar outros gatilhos?