Os índices BRIN funcionam melhor (ou apenas) em tabelas onde os dados são agrupados em armazenamento físico.
Existe uma maneira de verificar isso de antemão, além de testar ou considerar a lógica que cria os dados?
No meu caso, suspeito que minha tabela esteja ordenada por ID do cliente, mas não tenho certeza se isso é consistente o suficiente.
Estou executando um data warehouse em uma instância do AWS RDS PostgreSQL. A maior parte do trabalho pesado é feita durante o lote noturno e muitas vezes usamos uma estratégia de reconstrução TRUNCATE, também para tabelas grandes (100 milhões de linhas).
Isso parece causar problemas com o autovacuum, entre 2 e 4 do lote noturno, 7 em cada 10 das instruções TOP SQL são instruções VACUUM ANALYZE para tabelas grandes:
e elas estão abraçando meu sistema RDS
e reduzindo o equilíbrio de bytes para 0, após o qual a máquina desacelera enormemente:
Obviamente seria mais sensato adiar a ANÁLISE DE VÁCUO para um período posterior, quando a máquina estiver quase ociosa.
Depois de ler alguma documentação, posso pensar em duas estratégias para fazer isso:
autovacuum_cost_delaypara um valor sensato. já que isso adiaria o processamento do Vácuo em geral (ou talvez o definiria com um valor razoável apenas para essas tabelas).No entanto, qual é um valor sensato neste caso? Eu li que o padrão é 2 milissegundos. Quanto maior é o valor sensato de 200ms? 10 segundos? 1 minuto? 60 minutos?
Estou procurando um valor sensato para começar a testar ou outro conselho que possa me ajudar.
Nota. a máquina tem 2cpu, 16GB m6g.large e estas são as configurações atuais para os parâmetros relacionados ao autovauccum:
Informações extras
@jjanes sim, mal atinge o equilíbrio de bytes 0, no entanto, este é um equilíbrio cuidadoso que realmente consegui alcançar. Eu regularmente encontrava a situação em que demorava muito para me recuperar de uma situação que, na verdade, caía para 0. Exemplo
Minha máquina então começa a acumular latência de leitura/gravação e DiskQueueDepth também
O carregamento em massa à noite preocupa muitas mesas (atualmente ~900), que são todas carregadas/transformadas através de jobs entre 23h e 6h30, sendo o horário de maior movimento entre 2h e 4h. Muitas mesas são pequenas, apenas algumas são bastante grandes.
@jjanes & @frank-heikens, qual versão posterior faz diferença? aqui estão duas capturas de tela da situação antes e depois da migração de 14 para 15: Antes: Depois
:
Atualização Implementada sugestão de @Laurence Albe. Observações:
Equilíbrio de bytes muito melhor:
O banco de dados carrega muito mais uniformemente:
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?
Eu tenho uma grande mesa junta nas chaves. O plano de explicação mostra que a maior parte do tempo é gasta na classificação.
Existe algo que eu possa fazer para evitar as grandes etapas de classificação? Posso pré-ordenar a tabela?
Consulte e planeje aqui: https://explain.dalibo.com/plan/15a6a91492g8g935#plan/node/5
Ambas as tabelas já possuem um índice na chave, assim, mas esse índice parece não ser usado:
CREATE UNIQUE INDEX "stage_fact_revenue_900_idx_a" ON "stage"."stage_fact_revenue_900_add_dims" USING BTREE ("date","billed_relation_id","subject_client_id","identifier","revenue_type");
CREATE UNIQUE INDEX "fact_revenue_idx_a" ON "star"."fact_revenue" USING BTREE ("date","identifier","billed_relation_id","subject_client_id","revenue_type");
Eu tenho uma junção de tabela grande nas chaves que não usa o índice.
Consulte e planeje aqui : https://explain.dalibo.com/plan/15a6a91492g8g935#plan/node/5
Ambas as tabelas possuem um índice na chave, assim:
CREATE UNIQUE INDEX "stage_fact_revenue_900_idx_a" ON "stage"."stage_fact_revenue_900_add_dims" USING BTREE ("date","billed_relation_id","subject_client_id","identifier","revenue_type");
CREATE UNIQUE INDEX "fact_revenue_idx_a" ON "star"."fact_revenue" USING BTREE ("date","identifier","billed_relation_id","subject_client_id","revenue_type");
mas o índice não é usado (consulte o plano de consulta).
Alguma pista de por que isso não está acontecendo? As maiores etapas são classificadas, posso pré-classificar as tabelas para evitar isso?
Quero comparar uma lista de IDs separados por vírgula com o resultado de uma consulta, algo assim:
select * from (values (2201322723),
(2201318904),
(2201299380),
(2164969641),
(5682476934),
(2201314720),
) as t(object_id)
EXCEPT
select object_id from star.dim_partner where entity = 'partners' and is_active is true;
Os trabalhos acima, no entanto, exigia que eu usasse um editor de texto com suporte baseado em colunas para adicionar colchetes (a lista era realmente um pouco mais longa).
Existe uma maneira mais fácil/melhor de converter uma lista separada por vírgulas em uma tabela (temp) com o PostgreSQL?
um pouco como:
select item as object_id from ARRAY[6058271246, 2201299240, 1801904030, 2097401903];
?
Isso me permitirá recortar e colar qualquer lista de IDs entre os colchetes.
Eu tenho uma consulta que usa uma subconsulta ( select min/max(date) from stage.stage_net_subscription_010_filter_and_net_pds) para encontrar datas mínimas e máximas de uma tabela.
Parece que as subconsultas são repetidas com muita frequência.
Consulta:
SELECT
dim_date.date AS date
, stage_net_subscription_020_classes.client_id AS client_id
, stage_net_subscription_020_classes.product_id AS product_id
FROM star.dim_date dim_date
CROSS JOIN stage.stage_net_subscription_020_classes stage_net_subscription_020_classes
where date >= (select min(date) from stage.stage_net_subscription_010_filter_and_net_pds)
and date <= (select max(date) from stage.stage_net_subscription_010_filter_and_net_pds);
A opção Painel desapareceu do menu. Agora não consigo mais ver os bons gráficos.
O que eu preciso para recuperá-lo
Estou usando a versão 4.17?
Na resposta a Como gerenciar PRIVILÉGIOS PADRÃO para USUÁRIOS em um DATABASE vs SCHEMA?
Eu vejo a linha \connect hostdbpor que e quando preciso dessa linha?
Estou executando a linha SQL de criações de função de um arquivo .sql