From: | Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com> |
---|---|
To: | Jason Ralph <jralph(at)affinitysolutions(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: pg_upgrade —link does it remove table bloat |
Date: | 2020-02-13 18:16:09 |
Message-ID: | a265e511-c00f-16dc-4a80-0e690bd0f10b@aklaver.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2/13/20 10:04 AM, Jason Ralph wrote:
>> Well table bloat and table statistics are two different things. Bloat is the accumulation of dead or potentially dead tuples whose space has not been marked > as available for reuse by VACUUM or whose space has been returned to the OS with VACUUM FULL. For more information see:
>
> Thanks for the helpful response @Adrian Klaver,
> Let me try to rephrase my question,
> If a table has bloat before the upgrade, autvacuum was not aggressive enough, once pg_upgrade is complete, the same table will contain the same amount of bloat(dead tuples)? Meaning its not the same as pg_dump / pg_restore since it’s a hard link to the previous data location. Pg_upgrade with link will not recreate the table.
Yes pg_upgrade is a transfer of the binary data(sort of) whereas
pg_dump/restore is a logical transfer. So pg_upgrade via copy/clone/link
will not recreate user tables. For a good overview see IMPLEMENTATION
file in src:
>
> Jason Ralph
--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com
From | Date | Subject | |
---|---|---|---|
Next Message | Jason Ralph | 2020-02-13 19:07:39 | RE: pg_upgrade —link does it remove table bloat |
Previous Message | Jason Ralph | 2020-02-13 18:04:30 | RE: pg_upgrade —link does it remove table bloat |