Mikko Rantalainen's questions

De acordo com os comentários dos usuários, as somas de verificação de dados do PostgreSQL têm sobrecarga mínima de tempo de execução (CPU e armazenamento), mas permitiriam (entre outras coisas) o uso pg_rewindde recuperação pontual (PITR). No entanto, as somas de verificação de dados não são habilitadas por padrão e ativá-las no cluster HA já existente não é possível sem um tempo de inatividade bastante significativo. (Se entendi corretamente, você não pode habilitar checksums apenas no hot-standby e promovê-lo como novo mestre depois que habilitar os checksums foram concluídos no hot-standby.)

Existem alguns problemas pouco conhecidos se as somas de verificação de dados foram ativadas por padrão? Ou o estado padrão (somas de verificação desabilitadas) é apenas devido a razões históricas , embora habilitar somas de verificação de dados faça muito mais sentido em todos os casos?

Temos um servidor PostgreSQL 9.5 ocupado com tráfego semelhante ao OLTP, onde os pg_stat_all_tables.idx_scanvalores aumentam com uma taxa considerável enquanto estamos tendo problemas de desempenho.

Isso ( idx_scanaumentar) realmente significa que

1. o sistema está realmente executando muitas varreduras completas por meio de índices (ou seja, lendo todo o índice do disco, se ainda não estiver no cache), ou
2. o sistema está realmente obtendo apenas algumas tuplas ("linhas") desses índices (ou seja, usando o índice conforme pretendido)?

Se a opção 1 for verdadeira, como descobrir como colocar o sistema no estado 2? Preciso de alguns índices adicionais ou algumas das minhas consultas são ruins? Todas as consultas obtêm um bom desempenho enquanto o sistema está sob carga baixa, mas durante uma carga muito alta praticamente qualquer consulta pode ter um tempo de execução inesperadamente ruim.

(A documentação em https://www.postgresql.org/docs/current/monitoring-stats.html diz apenas "Número de verificações de índice iniciadas nesta tabela".)

Temos um banco de dados onde uma tabela contém dados temporários serializados que precisam ser mantidos por vários momentos (geralmente entre dezenas de minutos e duas semanas). Também temos um processo em segundo plano de baixa prioridade que remove as linhas antigas da tabela. O processo em segundo plano remove até 1.000 linhas durante uma transação:

delete from temporarydata
    where id in (
        select id from temporarydata
            where (created + ttl) <= 1553755330 limit 1000
    )

O 1553755330no exemplo é o número atual de segundos desde a época do UNIX e createdcontém segundos desde a época do UNIX em que os dados foram adicionados e ttlcontém o número de segundos em que os dados devem ser mantidos ativos.

Tecnicamente, isso funciona, mas existem cerca de 2 milhões de linhas nos dados temporários e a subseleção fica muito lenta porque a soma exige uma varredura sequencial na tabela para encontrar todas as linhas correspondentes. Isso causa uma carga extra em segundo plano no banco de dados.

> explain (analyze,verbose,timing,buffers) select id from temporarydata
        where (created + ttl) <= 1553755330 limit 1000

Limit  (cost=0.00..402.34 rows=1000 width=16) (actual time=6735.811..6735.811 rows=0 loops=1)
  Output: id
  Buffers: shared hit=3068 read=230500
  ->  Seq Scan on public.temporarydata  (cost=0.00..262980.99 rows=653622 width=16) (actual time=6735.809..6735.809 rows=0 loops=1)
        Output: id
        Filter: ((temporarydata.created + temporarydata.ttl) <= 1553755330)
        Rows Removed by Filter: 1916405
        Buffers: shared hit=3068 read=230500
Planning time: 0.402 ms
Execution time: 6735.849 ms

Eu prefiro apenas adicionar um novo índice que sempre pode conter a soma do created + ttlque o PostgreSQL foi capaz de usar para esta consulta automaticamente. Isso é possível com alto desempenho?

(Estou pensando em reescrever o código do aplicativo para salvar createde expiresem vez de ttlwhere expiresis created+ ttl. Então eu calculo lógica ttlcomo diferença desses valores. Acho que o aplicativo não emite consultas pesadas ttlsozinho.)

Tenho um servidor postgres 9.1 rodando e faço backups com

pg_dumpall -c -f /nfs/backup/fulldump.sql

Estou testando restaurar o backup para outro servidor com

psql -f /nfs/backup/fulldump.sql

durante a execução como usuário postgrese recebo dois erros

psql:/nfs/backup/fulldump.sql:27: ERROR:  current user cannot be dropped
psql:/nfs/backup/fulldump.sql:36: ERROR:  role "postgres" already exists

Eu entendo que estes são causados ​​por comandos

DROP ROLE postgres;
CREATE ROLE postgres;

no despejo de backup.

É possível restaurar de alguma forma o dump pg_dumpall -csem ter um único erro?