mj_'s questions

Tenho dois bancos de dados Postgres 13 no AWS RDS.

• Um é mestre, o outro é escravo e usa replicação lógica.
• A replicação ficou para trás em cerca de 350 Gb.
• O escravo ficou com a CPU no limite nos últimos quatro dias por causa de alguns trabalhos em andamento, então não tenho certeza de qual replicação lógica conseguiu replicar durante esse tempo.
• Eu matei esses trabalhos e agora a CPU no mestre e no escravo está baixa.
• Olho para o assinante via select * from pg_stat_subscription;e vejo que latest_end_lsnestá avançando, embora muito lentamente.
• O editor diz que os atrasos de gravação/liberação/reprodução estão todos 13 minutos atrasados, mas tem sido assim durante a maior parte do dia.
• Não vejo erros nos logs do publicador ou do assinante, além de alguns erros simples de SQL que os usuários têm cometido.

Há algo que eu possa fazer aqui? Anteriormente, eu defini wal_receiver_timeouto timeout como 0 porque tive problemas de replicação, e isso ajudou. Gostaria de ter alguma visibilidade aqui para ter algum tipo de confiança de que ele vai funcionar, mas além desses lsnvalores e logs do banco de dados, não tenho certeza do que verificar.

Estou olhando nossa replicação no Postgres. Temos lógica e binária acontecendo. Eu faço um select * from pg_stat_replication order by state;e vejo os valores lsn enviados/escrever/liberar/reproduzir. Eles se parecem 31855/17CB26A8e os valores avançam com o tempo.

Para obter a posição atual, faço a select pg_current_wal_lsn();e está em 319E1/73CDD590.

Meu problema é que à medida que os valores avançam, eles quase chegam à posição atual e depois “rolam” e recomeçam. Isso é normal?

Estou na v13.10.

Eu tenho uma tabela com um monte de colunas. Entre eles facility_ide po_date. Estou escrevendo uma consulta complexa e tenho um índice nessas duas colunas. Você pode ver na saída do planejador abaixo que o Postgres está usando esse índice como a condição do índice quando está se juntando à minha facilitytabela.

Minha dúvida é na verdade em relação à presença de colunas enumeradas na Filter:linha abaixo. exclude, verified, e deletednão estão no índice referenciado na parte superior e, então, como o Postgres está realmente obtendo os dados nessas colunas? Eu esperava que uma verificação completa da tabela fosse explicitamente citada, mas não há uma à vista em nenhum lugar. Uma varredura de tabela completa pode ser ocultada silenciosamente em um arquivo Filter?

Esta tabela tem 50 milhões de linhas e estou no Postgres 10. Além disso, essa parte da consulta está em um CTE.

->  Index Scan using clustered_table_facility_id_po_date_idx on clustered_table cp  (cost=0.56..1401.08 rows=31929 width=37) (actual time=0.021..5.331 rows=9572 loops=3640)
      Index Cond: (facility_id = af.id)
      Filter: ((NOT exclude) AND (verified IS NULL) AND (deleted IS NULL))
      Rows Removed by Filter: 2819

Eu tenho uma tabela que é de +80 GB com 200 milhões de linhas. Estou tentando agilizar e notei que tem um grande número de colunas varchar. No esquema, seus comprimentos variam de 15 caracteres a 250 caracteres com a maioria definida em 50. O comprimento total de todos os varchars é de 850 bytes. No uso real, muitos dos campos são nulos ou as strings são muito curtas.

Eu sei que o Postgres usa um tamanho de página de 8k. Agora, se eu tiver que fazer uma varredura completa da tabela e assumindo o pior cenário, 8k / 850 = 9,6 registros por página. Passar pela minha tabela completa vai (e leva) muito tempo. Na realidade, no entanto, como a maioria desses campos está vazia, quanto espaço será alocado no disco para esses varchars? Haverá mais registros por página ou o Postgres coloca um pouco de preenchimento apenas para facilitar as atualizações posteriores?

A razão pela qual estou perguntando é porque estou explorando a ideia de melhorar o desempenho chutando o máximo possível das colunas varchars acessadas com pouca frequência desta tabela e para outra que acessaríamos por meio de uma junção.

Qualquer confirmação ou negação da minha lógica é apreciada.

mj

Eu tenho uma tabela com ~ 200 milhões de linhas que tem uma coluna de data. Eu quero realizar a seguinte consulta.

select my_date from my_table 
where my_date > to_date('2020-10-01', 'YYYY-MM-DD');

À medida que a consulta está sendo executada, em cada my_date em cada linha, o valor de data no banco de dados será comparado com minha data de string convertida em um objeto de data. O postgres é inteligente o suficiente para perceber que essa transformação de string para objeto de data precisa ser executada apenas uma vez ou será executada em cada linha?