Re: VACUUM's ancillary tasks

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: Vik Fearing <vik(at)2ndquadrant(dot)fr>, Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: VACUUM's ancillary tasks
Date: 2016-10-07 13:14:37
Message-ID: CA+TgmoaEp6FGdCm4MJvpptDPUQKEhGXvkt5JSV=_xg_rG+we6g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2016-10-07 13:20:23 Re: Question / requests.
Previous Message Michael Paquier 2016-10-07 12:05:32 Re: pg_rewind and ssl test suites don't work if '.' is not in @INC