Tem não.
Seria impossível ter uma transação pegando mais da metade das linhas da
tabela.
>
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>From manual:
*VACUUM FULL rewrites the entire contents of the table into a new disk file
with no extra space, allowing unused space to be returned to the operating
system. This form is much slower and requires an exclusive lock on each
table while it is being processed.*
Link:
Fabiano, isso eu já tinha entendido, mas pelo teste que fiz minha tabela
(inchada) tem 120GB e ela depois de um dump/restore fica com 30GB.
Eu tenho 87 GB de espaço livre e o vacuum full deu falta de espaço.
Eu imaginei que só precisasse apenas desses 30GB extras para fazer o vacuum
full e não os
Vale lembrar que essa definição do vacuum full só vale a partir da versão
9.0.0 do Postgres. Antes a implementação do comando varria a tabela
reorganizando os registros fisicamente nos blocos/páginas do disco.
Luiz, qual é a versão do seu banco?
9.3
Lembrando também que você pode tentar aumentar
Luiz,
Você está considerando o tamanho dos índices da tabela também?
Att.
2016-03-31 10:22 GMT-03:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:
> Vale lembrar que essa definição do vacuum full só vale a partir da versão
> 9.0.0 do Postgres. Antes a implementação do comando varria a
Você está considerando o tamanho dos índices da tabela também?
Não. Ainda tem um índice de 2.5GB
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
On 31-03-2016 11:24, Luiz Carlos L. Nogueira Jr. wrote:
> Você está considerando o tamanho dos índices da tabela também?
>
> Não. Ainda tem um índice de 2.5GB
>
Luis,
Como é o layout de discos dessa sua instância? Essa tabela e índices
está em um tablespace separado?
Att,
--
Fabrízio de
Em qui, 31 de mar de 2016 18:37, Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com> escreveu:
> Como é o layout de discos dessa sua instância? Essa tabela e índices
> está em um tablespace separado?
>
> Tudo junto
>
pg_xlog também? Pode ser ele que cresce durante a operação.
Palmada no seu
Flávio,
PG_XLOG Tá separado, nem se preocupe
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_byteblock
INFO: vacuuming "public.jbpm_byteblock"
INFO: "jbpm_byteblock": found 15505882 removable, 18439352
nonremovable row versions in 4762603 pages
DETAIL: 0 dead row versions cannot be removed yet.
2016-03-31 16:10 GMT-03:00 Luiz Carlos L. Nogueira Jr. <
lcnogueir...@gmail.com>:
> [QUERY] VACUUM FULL ANALYZE VERBOSE jbpm_byteblock
> INFO: vacuuming "public.jbpm_byteblock"
> INFO: "jbpm_byteblock": found 15505882 removable, 18439352
> nonremovable row versions
versão 9.3
Nesse contexto isso não é relavante.
--É relevante porque eu garanto que não estão sendo incluídas nem apagadas
as linhas. (pra naõ termos distorções nos valores)
Durante a execução do ANALYZE o processo é feito por amostragem, limitadas
em até 30.000 linhas. Dessas linhas, ele
Pessoal,
As linhas deletadas de uma tabela podem estar "lockadas" por alguém?
Pergunto isso por que tenho uma tabela de 120GB, que depois de um vacuum
full ficaria com um valor bem menor que 50GB e deu erro por falta de
espaço, só que tenho 87GB de espaço livre.
Existe algum motivo pro VACUUM
Bom dia. O fato do vacuum full não ter liberado o espaço em disco não quer
dizer que as linhas estejas "lockadas", mas ela simplesmente pode estar
visível para alguma transação ativa no banco. Veja se não existe alguma
conexão ativa que possa estar usando estas linhas através da view
Vale lembrar que essa definição do vacuum full só vale a partir da versão
9.0.0 do Postgres. Antes a implementação do comando varria a tabela
reorganizando os registros fisicamente nos blocos/páginas do disco.
Luiz, qual é a versão do seu banco?
Lembrando também que você pode tentar aumentar
15 matches
Mail list logo
