Re: VACUUM's ancillary tasks

On Wed, Oct 19, 2016 at 2:44 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Sun, Oct 16, 2016 at 3:35 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> > On Fri, Oct 7, 2016 at 6:14 AM, Robert Haas <robertmhaas(at)gmail(dot)com>
> wrote:
> >> On Thu, Oct 6, 2016 at 8:40 PM, Jeff Janes <jeff(dot)janes(at)gmail(dot)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