| From: | Jeff Janes <jeff(dot)janes(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 14:52:24 |
| Message-ID: | CAMkU=1yJ+SRxJ2VOQ+DPMG7QaUO0sY5qd=jgfxjnyzWB8SzANw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Jun 20, 2016 at 3: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
Are you sure that that is the case with pg_bulkload specifically? It
bypasses the shared buffers, so it would not surprise me if it
bypasses the free space map as well, and thus always appends its data
to the end of the table.
Cheers,
Jeff
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scott Mead | 2016-06-20 15:03:49 | Re: R: Vacuum full: alternatives? |
| Previous Message | Martín Marqués | 2016-06-20 14:42:21 | Re: R: Vacuum full: alternatives? |