Re: R: Vacuum full: alternatives?

Поиск
Список
Период
Сортировка
От Martín Marqués
Тема Re: R: Vacuum full: alternatives?
Дата
Msg-id ee90647d-2bd2-27ee-f8fa-12e2f36b9204@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: R: Vacuum full: alternatives?  (Jeff Janes <jeff.janes@gmail.com>)
Список pgsql-general
El 20/06/16 a las 11:52, Jeff Janes escribió:
> On Mon, Jun 20, 2016 at 3:13 AM, Andreas Kretschmer
> <andreas@a-kretschmer.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.

I didn't do a super intensive check of pg_bulkload, but AFAICS it does
batches of COPY with PQputCopyData.

If the relation has free space which was reclaimed by vacuum/autovacuum
it will try to use that space and not extend the relation (which is more
expensive). This happens if used space on those pages is lower than the
fillfactor set for that table.

IMO, he should start setting autovacuum more aggressively, or running
aggressive vacuum, and see how that works.

Also, install pgstattuple and check free space on the relation to see
how much dead tuples and free space there is.

Those are my 2 cents.

--
Martín Marqués                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services


В списке pgsql-general по дате отправления:

Предыдущее
От: Melvin Davidson
Дата:
Сообщение: Re: R: Vacuum full: alternatives?
Следующее
От: John R Pierce
Дата:
Сообщение: Re: R: Vacuum full: alternatives?