Início / user-278932

KaliTheGreat's questions

Martin Hope
KaliTheGreat
Asked: 2024-08-24 20:46:41 +0800 CST
  • 6

Tenho uma tabela user_issuescom 3 colunas: id, component_ide pathe preciso filtrá-la, mas tuplas de component_ide path.

Então usei a seguinte consulta para conseguir isso:

SELECT id 
FROM user_issues ui 
JOIN (VALUES ($1, $2), ($3, $4)) AS v(component_id, path) ON ui.component_id = v.component_id AND ui.path = v.path;

Gostaria de saber se existe uma maneira mais elegante ou eficiente de conseguir isso (em vez de usar a VALUEScláusula para criar um conjunto de linhas (tuplas)).

postgresql
Martin Hope
KaliTheGreat
Asked: 2024-02-21 16:00:03 +0800 CST
  • 8

Há um DB com uma quantidade desconhecida de índices exclusivos corrompidos. Atualmente, eu os descubro um por um quando tento REINDEX DATABASE CONCURRENTLY <db_name>, lidar com a violação de duplicação específica (manipulação de dados, principalmente exclusão de duplicações usando scripts), reindexar a tabela ou índice específico e continuar para o próximo índice (novamente, apenas logo após descobri-lo usando REINDEX DATABASE CONCURRENTLY).

Sem mencionar que cada vez que recebo índices com o sufixo '_ccnew', que AFAIK são índices que tentaram ser criados por uma reindexação anterior simultaneamente, mas não puderam ser feitos, geralmente porque estão violando uma verificação de exclusividade. As tentativas fracassadas de reindexação simultânea ficarão lá e devem ser descartadas manualmente.

A reindexação simultânea é usada para evitar um desligamento.

Quero reduzir essas "viagens de ida e volta" de busca pela próxima violação e me pergunto se há uma maneira mais eficiente de obter dados gerais sobre o status de todas as corrupções de índice ou violações exclusivas que um banco de dados Postgres possui.

postgresql
Martin Hope
KaliTheGreat
Asked: 2024-01-04 19:17:52 +0800 CST
  • 7

Eu tenho uma tabela que possui índice exclusivo:

CREATE UNIQUE INDEX IF NOT EXISTS tb_sha256_key_idx ON blob_props (sha256, key);

Quero alterá-lo para chave primária durante a migração do banco de dados e há duas maneiras:

  1. ALTER TABLE tb ADD CONSTRAINT tb_pkey PRIMARY KEY USING INDEX tb_sha256_key_idx;

  2. DROP INDEX tb_sha256_key_idxe entãoALTER TABLE tb ADD PRIMARY KEY (sha256, key);

sha256e keynão são colunas nulas (portanto, deve funcionar bem).

Tenho algumas preocupações em relação às duas abordagens e estou debatendo qual é a abordagem correta durante uma migração de banco de dados:

A segunda abordagem é melhor porque, ao descartar/criar, melhoraremos drasticamente o fator de agrupamento do índice e seu tamanho devido à fragmentação. É preferível do ponto de vista do desempenho. Mas criar um índice em uma tabela grande causaria arquivos temporários grandes (é por isso que usamos REINDEX na maioria das vezes e criamos novos índices apenas como último recurso).

Deseja aprofundar a discussão e obter algumas reivindicações e/ou mais opiniões sobre esse cenário.

postgresql
Martin Hope
KaliTheGreat
Asked: 2023-10-17 21:41:32 +0800 CST
  • 6

Preciso de sugestões/ideias para otimizar a seguinte consulta:

SELECT COUNT(*) 
FROM (SELECT 1 
      FROM f 
      WHERE parent_sha256 = $1 
        AND parent_sha256 <> sha256 
      LIMIT 1) AS row_count;

O que é necessário para verificar se um parent_sha256 específico tem algum filho direto. A tabela é muito grande (50 milhões de linhas) e a consulta é muito lenta (6 a 12 minutos) quando há 700 mil a 900 mil linhas correspondentes, parent_sha256 = $1mas 0 linhas correspondentes parent_sha256 = $1 AND parent_sha256 <> sha256.

Nesse caso, o banco de dados deve ultrapassar todos os 700k ~ 900k.

Vale ressaltar que existem índices em parent_sha256e sha256.

postgresql