2016-12-17 21:36 GMT-02:00 Euler Taveira :
> Para mover as tablespaces para outro local você tem duas opções: (i)
> criar tablespace nova, ir movendo logicamente (... SET TABLESPACE) todos
> os objetos e apagar a tablespace antiga ou (ii) parar o serviço, mover o
> conteúdo
2016-12-16 8:25 GMT-02:00 Cleiton Luiz Domazak :
> O dobro do tamanho aparece quando executo o comando select
> pg_size_pretty(pg_database_size('teste2'));
>
> Neste comando ele calcula fisicamente o tamanho e conta os 2 diretórios?
> Pra mim isso é novidade (e não estou
On 16-12-2016 09:38, Crauss, Jacson wrote:
> Eu não sabia disso, obrigado! Para que eu corrija isso, preciso dropar
> tudo e fazer o restore novamente com as tablespaces criadas em outro
> lugar, ou existe alguma espécie de "move" de tablespaces?
>
Para mover as tablespaces para outro local você
2016-12-15 23:24 GMT-02:00 Euler Taveira :
> Você e o Cleiton estão comentendo o mesmo erro: *não* se cria
> tablespaces dentro do diretório $PGDATA ou qualquer subdiretório dele
> (vide [1]). Muitos confundem o conceito do Oracle com Postgres e acham
> que o equivalente de
Em 15 de dezembro de 2016 23:24, Euler Taveira
escreveu:
> [...]
>
>
> [1]
> https://www.postgresql.org/message-id/CA%2BTgmobZLyLU8tFCbMqbjMWB6t%2B%
> 3DERaDo820uQEJCVAQK_Paow%40mail.gmail.com
Valeu pela explicação, Euler! Não fazia ideia, aliás, passei batido pelo
2016-12-15 23:24 GMT-02:00 Euler Taveira :
> On 15-12-2016 10:16, Crauss, Jacson wrote:
> > Tablespace server antigo:
> > ~/dados/pg_tblspc/tblspc_pgh
> > $ du -skh
> > 411G.
> >
> Você e o Cleiton estão comentendo o mesmo erro: *não* se cria
> tablespaces dentro do
On 15-12-2016 10:16, Crauss, Jacson wrote:
> Tablespace server antigo:
> ~/dados/pg_tblspc/tblspc_pgh
> $ du -skh
> 411G.
>
Você e o Cleiton estão comentendo o mesmo erro: *não* se cria
tablespaces dentro do diretório $PGDATA ou qualquer subdiretório dele
(vide [1]). Muitos confundem o
Aqui tivemos um problema desses com uma tabela monstruosa que estourou a
partição no meio de um vacuum full..
Aí a tabela que seria duplicada pelo vacuum ficou "perdida", apenas
ocupando espaço, mas sem fazer nada.
___
pgbr-geral mailing list
Em 15 de dezembro de 2016 11:40, Crauss, Jacson escreveu:
>
> 2016-12-15 11:37 GMT-02:00 Rafael Fialho :
>
>> Somente analyze já serve.
>
>
>
> É, rodei o analyze em uma base menor para ser rápido, e não resolveu. Vou
> deixar rodando na base maior, vai
2016-12-15 11:37 GMT-02:00 Rafael Fialho :
> Somente analyze já serve.
É, rodei o analyze em uma base menor para ser rápido, e não resolveu. Vou
deixar rodando na base maior, vai demorar bastante, depois informo se
funcionou (não sei se vai, ja que na menor não foi,
Em 15 de dezembro de 2016 11:36, Crauss, Jacson escreveu:
>
> 2016-12-15 11:29 GMT-02:00 Rafael Fialho :
>
>> Primeiramente, eu refaria o teste sem realizar o vacuum full. Poderia
>> também executar um analyze na base de dados antes de executar as queries
2016-12-15 11:29 GMT-02:00 Rafael Fialho :
> Primeiramente, eu refaria o teste sem realizar o vacuum full. Poderia
> também executar um analyze na base de dados antes de executar as queries
> para verificar o tamanho (ou neste momento também). Não tenho certeza de
> como
Em 15 de dezembro de 2016 11:16, Crauss, Jacson escreveu:
>
> Estou fazendo uma troca de servidor das bases de testes. Fiz um dumpall no
> servidor antigo, e restaurei no novo servidor (zerado, sem nenhuma base, só
> com a instalação do PostgreSQL). Ao terminar o restore, fiz o
On Wed, Oct 26, 2016 at 10:45 AM, Fabrízio de Royes Mello <
fabri...@timbira.com.br> wrote:
> Isso é normal, porque o metacomando \dt+ do psql [1] retorna o tamanho
> da tabela (incluindo FSM, VM e TOAST apartir da 9.0), ou seja, não
> considera índices.
>
Estou fazendo uma troca de servidor
On 26-10-2016 10:17, Sebastian Webber wrote:
> Curioso do teu problema, eu fiz um teste aqui, veja:
>
> sebastian=# create table foo (id serial primary key, nome text);
> CREATE TABLE
> sebastian=# insert into foo (nome) select 'Nome ' ||
> generate_series(1,100);
> INSERT
On Wed, Oct 26, 2016 at 10:17 AM, Sebastian Webber
wrote:
> Curioso do teu problema, eu fiz um teste aqui, veja:
>
> sebastian=# create table foo (id serial primary key, nome text);
> CREATE TABLE
> sebastian=# insert into foo (nome) select 'Nome ' ||
>
Curioso do teu problema, eu fiz um teste aqui, veja:
sebastian=# create table foo (id serial primary key, nome text);
CREATE TABLE
sebastian=# insert into foo (nome) select 'Nome ' ||
generate_series(1,100);
INSERT 0 100
sebastian=# \dt+
List of relations
Schema |
2016-10-26 9:13 GMT-02:00 Sebastian Webber :
>
>
> Em 25 de outubro de 2016 18:22, Cleiton Luiz Domazak <
> cleitondoma...@gmail.com> escreveu:
>
>>
>>
>> 2016-10-25 17:28 GMT-02:00 Sebastian Webber :
>>
>>>
>>>
>>> Em 25 de outubro de 2016 16:02,
Em 25 de outubro de 2016 18:22, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:
>
>
> 2016-10-25 17:28 GMT-02:00 Sebastian Webber :
>
>>
>>
>> Em 25 de outubro de 2016 16:02, Cleiton Luiz Domazak <
>> cleitondoma...@gmail.com> escreveu:
>>
>>> Boa tarde.
>>>
>>>
2016-10-25 17:28 GMT-02:00 Sebastian Webber :
>
>
> Em 25 de outubro de 2016 16:02, Cleiton Luiz Domazak <
> cleitondoma...@gmail.com> escreveu:
>
>> Boa tarde.
>>
>> Preciso calcular o tamanho total de uma base em disco, não logicamente
>> pela PostgreSQL.
>>
>
> Dá uma
Em 25 de outubro de 2016 16:02, Cleiton Luiz Domazak <
cleitondoma...@gmail.com> escreveu:
> Boa tarde.
>
> Preciso calcular o tamanho total de uma base em disco, não logicamente
> pela PostgreSQL.
>
Dá uma olhada na função pg_database_size[1].
>
> Todas as bases estão criadas em cima de
Boa tarde.
Preciso calcular o tamanho total de uma base em disco, não logicamente pela
PostgreSQL.
Todas as bases estão criadas em cima de tablespaces, e como cada base tem a
sua tablespace especifica, os temp files são criados em uma delas também. E
o volume de WAL em disco é irrelevante nesse
22 matches
Mail list logo