Re: VACUUM's ancillary tasks

Поиск
Список
Период
Сортировка
От Haribabu Kommi
Тема Re: VACUUM's ancillary tasks
Дата
Msg-id CAJrrPGc9hqLNEAjDyEgP1wUuBdH5qv-ucaNpWcT-4nWSoB5T9w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: VACUUM's ancillary tasks  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers


On Wed, Oct 19, 2016 at 2:44 AM, Robert Haas <robertmhaas@gmail.com> wrote:
On Sun, Oct 16, 2016 at 3:35 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Fri, Oct 7, 2016 at 6:14 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>> On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
>> > In commit 37484ad2aacef5ec7, you changed the way that frozen tuples were
>> > represented, so that we could make freezing more aggressive without
>> > losing
>> > forensic evidence.  But I don't think we ever did anything to actually
>> > make
>> > the freezing more aggressive.
>>
>> See 3cff1879f8d03cb729368722ca823a4bf74c0cac.  The objection to doing
>> it in other cases is that it adds write-ahead log volume which might
>> cause its own share of problems.  There might be some way of getting
>> ahead of that, though.  I think if we piggyback on an existing WAL
>> record like XLOG_HEAP2_CLEAN or XLOG_HEAP2_VISIBLE the impact might be
>> minimal, but I haven't been dedicated enough to try to write the
>> patch.
>>
>> > When I applied the up-thread patch so that pgbench_history gets autovac,
>> > those autovacs don't actually cause any pages to get frozen until the
>> > wrap
>> > around kicks in, even when all the tuples on the early pages should be
>> > well
>> > beyond vacuum_freeze_min_age.
>>
>> If the pages are already all-visible, they'll be skipped until
>> vacuum_freeze_table_age is reached.
>
> So if I set vacuum_freeze_min_age to zero, then they should become
> all-visible and all-frozen at the same time, and avoid that problem?

Hmm.  I *think* so...

> From the docs on vacuum_freeze_min_age: "Increasing this setting may avoid
> unnecessary work if the rows that would otherwise be frozen will soon be
> modified again".  How much work is that? Presumably they are already getting
> marked visible, is marking them frozen too a meaningful amount of extra
> work?  Is it just the extra WAL record?

Yeah, the extra WAL record is the main thing, I think.

Closed in 2016-11 commitfest with "returned with feedback" status as per my
understanding from the recent mails on the thread.

Please feel free to change the status if the current status is doesn't reflect the
actual status.

Regards,
Hari Babu
Fujitsu Australia

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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Fix checkpoint skip logic on idle systems by tracking LSN progress
Следующее
От: Haribabu Kommi
Дата:
Сообщение: Re: pg_xlogdump follow into the future