From: | ghiureai <isabella(dot)ghiurea(at)nrc-cnrc(dot)gc(dot)ca> |
---|---|
To: | Igor Neyman <ineyman(at)perceptron(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: PG 9.5 2 tables same DDL with diff size |
Date: | 2018-01-10 18:49:41 |
Message-ID: | c80b2d05-a168-f296-408b-1f3ff441f8d0@nrc-cnrc.gc.ca |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Thank you Igor, I was able to eliminate the 15GB bloating for a 35GB
table size , only after I restart the Pg server with one single
connections and run a full vacuum for table.
Isabella
On 10/01/18 11:10 AM, Igor Neyman wrote:
> -----Original Message-----
> From: Isabella Ghiurea [mailto:isabella(dot)ghiurea(at)nrc-cnrc(dot)gc(dot)ca]
> Sent: Wednesday, January 10, 2018 10:48 AM
> To: pgsql-performance(at)postgresql(dot)org
> Subject: RE: PG 9.5 2 tables same DDL with diff size
>
> Attention: This email was sent from someone outside of Perceptron. Always exercise caution when opening attachments or clicking links from unknown senders or when receiving unexpected emails.
>
>
> I run full vacuum and reindex on largest table (50GB) while there was no server activities so I assume no transaction was holding a lock on table since the full vacuum was able to run, anything where I should consider looking ?
>
>
> __________________________________________________________________________________________________________
>
> Yes, in pg_stat_activity look for idle transactions that started long time ago.
> To prevent vacuum from doing its job they don't need to lock the table, they could just prevent from cleaning "old" row versions.
>
> Regards,
> Igor Neyman
>
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2018-01-10 19:34:17 | Re: Query is slow when run for first time; subsequent execution is fast |
Previous Message | Igor Neyman | 2018-01-10 16:10:13 | RE: PG 9.5 2 tables same DDL with diff size |