brauliobo's questions

Alterei o parâmetro max_sync_workers_per_subscriptionno Amazon RDS Postgresql e verifiquei que ele foi alterado no banco de dados mestre:

db=> show max_sync_workers_per_subscription;
 max_sync_workers_per_subscription 
-----------------------------------
 2
(1 row)
db=> show max_sync_workers_per_subscription;
 max_sync_workers_per_subscription 
-----------------------------------
 4
(1 row)

O problema é que a replicação ainda está usando o valor antigo, 2pois o uso da CPU ainda usa apenas 2 núcleos para cada trabalhador de replicação lógica, o que significa que a configuração foi aplicada à assinatura.

Abaixo estão algumas configurações relevantes na réplica:

db=# show max_worker_processes;
 max_worker_processes 
----------------------
 8
(1 row)

db=# show max_logical_replication_workers;
 max_logical_replication_workers 
---------------------------------
 4
(1 row)

Estamos enfrentando muitas lentidão devido ao inchaço do índice. Ao tentar otimizar o índice, recriá-lo parece gerar um índice muito menor:

reviews_hotel_id_connection_id_review_date_created_at_review_id: índice original reviews_hotel_id_connection_id_review_date_created_at_new: duplicata exata do índice original, recriado

 reviews | reviews_hotel_id_connection_id_review_date_created_at_review_id | 5296 kB  
 reviews | reviews_hotel_id_connection_id_review_date_created_at_new       | 2944 kB    

O novo índice tem apenas 55% do tamanho do índice original!

A execução VACUUM ANALYSE reviewsnão resulta em nenhuma redução de índice!

A execução VACUUM FULL reviewsfaz com que o índice original tenha exatamente o mesmo tamanho que o novo índice:

 reviews | reviews_hotel_id_connection_id_review_date_created_at_new       | 2944 kB 
 reviews | reviews_hotel_id_connection_id_review_date_created_at_review_id | 2944 kB

Embora VACUUM FULLbloqueie a tabela mesmo para leituras! É uma opção para otimizar índices sem causar tempo de inatividade?

Estou enfrentando degradação de desempenho e uso crescente de armazenamento como resultado de registros novos e atualizados frequentes, causando fragmentação de índice e armazenamento.

VÁCUO não ajuda muito.

Infelizmente CLUSTER não é uma opção, pois causa tempo de inatividade e pg_repack não está disponível para AWS RDS.

Estou procurando alternativas hacky para CLUSTER. Um que parece funcionar bem nos meus testes locais é:

begin;

create temp table tmp_target as select * from target;

delete from target;
insert into target select * from tmp_target order by field1 asc, field2 desc;

drop table tmp_target;

commit;

A ordenação dos ctidlooks está correta com:

select ctid, field1, field2 from target order by ctid;

A questão é: isso parece bom? Vai bloquear a targettabela para SELECTconsultas que causam tempo de inatividade nos aplicativos? Existe uma maneira de listar os bloqueios envolvidos na transação?

Relacionado a consultas somente leitura de bloqueio de comando de cluster na réplica

Percebi que o clustering pode levar muito tempo e bloquear a tabela completamente, mesmo para leituras.

Tabelas organizadas por índice e clustering incremental seriam perfeitos, mas infelizmente eles não são suportados pelo PostgreSQL.

Agora eu percebo que ele também bloqueia as tabelas das réplicas, então aparentemente não há uma maneira de cluster sem ter muito tempo de inatividade?

A configuração rds.logical_replicationpara 1instâncias mestre e de réplica não ajudou.

Eu gostaria de agrupar quatro grandes mesas toda semana para um melhor desempenho.