From: | Melvin Davidson <melvin6925(at)gmail(dot)com> |
---|---|
To: | Andreas Kretschmer <andreas(at)a-kretschmer(dot)de> |
Cc: | Job <Job(at)colliniconsulting(dot)it>, "pgsql-general(at)postgresql(dot)org" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: R: Vacuum full: alternatives? |
Date: | 2016-06-20 12:28:52 |
Message-ID: | CANu8FiyYEjBf525jx+3qMcTyKB6JnxnhkFsO2VufTNyxa+m2Mw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Mon, Jun 20, 2016 at 6:13 AM, Andreas Kretschmer <andreas(at)a-kretschmer(dot)de
> wrote:
>
>
> Am 20.06.2016 um 11:43 schrieb Job:
>
>> Hi Andreas,
>>
>> I would suggest run only autovacuum, and with time you will see a not
>>> more growing table. There is no need for vacuum full.
>>>
>> So new record, when will be pg_bulkloaded, will replace "marked-free"
>> location?
>>
>
>
> exactly, that's the task for vacuum
>
>
>
> Andreas
>
>
> --
> Sent via pgsql-general mailing list (pgsql-general(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-general
>
>We do not delete everything at one (in this case the truncate woudl
resolve the problem).
Please, it is very important you provide PostgreSQL version & O/S, as
improvements to VACUUM may play a role here.
Is there any reason you cannot partition the table? Moving the data to
separate partitions
(based on a date or key field) will allow you to vacuum full only 1
partition at a time.
--
*Melvin Davidson*
I reserve the right to fantasize. Whether or not you
wish to share my fantasy is entirely up to you.
From | Date | Subject | |
---|---|---|---|
Next Message | Rakesh Kumar | 2016-06-20 12:29:30 | Re: R: Vacuum full: alternatives? |
Previous Message | Andreas Kretschmer | 2016-06-20 10:13:13 | Re: R: Vacuum full: alternatives? |