Início / dba / Perguntas / 237628
Accepted
Exelian
Asked: 2019-05-09 00:40:53 +0800 CST

Duração da recuperação de espaço em disco em tabelas muito grandes (mais de 2,5 bilhões de linhas)

  • 772

Estou usando o PostgreSQL 9.4.20 e tenho 1 tabela que em 1 ponto continha 2,5 bilhões de linhas. Começamos a migrar dados e reduzimos o tamanho da tabela para cerca de 280 milhões de linhas.

Se possível, gostaríamos de recuperar o espaço em disco usado. Eu li sobre VACUUM FULL e sei que isso resultará em um bloqueio de tabela completo durante a operação. Minha pergunta aqui é: dado que um VACUUM da tabela levará cerca de 12.000 - 13.000 segundos, existe alguma maneira de estimar quanto tempo um VACUUM FULL levará para o tamanho atual e anterior da tabela?

Está incluída uma das saídas VACUUM VERBOSE durante o processo de exclusão:

INFO:  vacuuming "public.redacted"
INFO:  scanned index "redacted_prop_id_3df0d554fdfe92ee_idx" to remove 85063130 row versions
DETAIL:  CPU 105.78s/340.93u sec elapsed 3633.81 sec.
INFO:  scanned index "redacted_pkey" to remove 85063130 row versions
DETAIL:  CPU 35.37s/269.95u sec elapsed 1147.31 sec.
INFO:  "redacted": removed 85063130 row versions in 811189 pages
DETAIL:  CPU 12.00s/17.68u sec elapsed 342.43 sec.
INFO:  scanned index "redacted_prop_id_3df0d554fdfe92ee_idx" to remove 39116682 row versions
DETAIL:  CPU 101.30s/346.25u sec elapsed 3576.71 sec.
INFO:  scanned index "redacted_pkey" to remove 39116682 row versions
DETAIL:  CPU 40.21s/237.76u sec elapsed 1219.00 sec.
INFO:  "redacted": removed 39116682 row versions in 879306 pages
DETAIL:  CPU 22.85s/40.58u sec elapsed 817.57 sec.
INFO:  index "redacted_prop_id_3df0d554fdfe92ee_idx" now contains 1597286875 row versions in 1
DETAIL:  121144639 index row versions were removed.
4169907 index pages have been deleted, 3055311 are currently reusable.
CPU 0.03s/0.00u sec elapsed 0.30 sec.
INFO:  index "redacted_pkey" now contains 1597377401 row versions in 5999520 pages
DETAIL:  124175137 index row versions were removed.
1209655 index pages have been deleted, 894966 are currently reusable.
CPU 0.01s/0.00u sec elapsed 0.17 sec.
INFO:  "redacted": found 107389052 removable, 820955017 nonremovable row versions in 7045430 oes
DETAIL:  0 dead row versions cannot be removed yet.
There were 13483069 unused item pointers.
0 pages are entirely empty.
CPU 382.60s/1408.62u sec elapsed 12543.69 sec.
INFO:  analyzing "public.redacted"
INFO:  "redacted": scanned 30000 of 15055610 pages, containing 3170455 live rows and 0 dead rosample, 1591104467 estimated total rows
postgresql

1 respostas

  1. Best Answer

    Eu escolhi uma abordagem diferente para recuperar o espaço em disco. Muitos dados foram usados ​​para os índices pkeye . prop_id_3df0d554fdfe92ee_idxFoi possível interromper todas as gravações na tabela, durante o qual emiti um REINDEXcomando para os índices individuais.

    Depois de reconstruir os índices, espaço em disco suficiente foi recuperado para permitir que uma tabela secundária fosse criada com base no conteúdo da tabela original. Em seguida, a tabela original foi excluída e a segunda tabela renomeada.

    • 0

relate perguntas