Re: New strategies for freezing, advancing relfrozenxid early - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: New strategies for freezing, advancing relfrozenxid early
Date
Msg-id 9bc85fb435df6f5fc2ececc00c0a086d41b755b4.camel@j-davis.com
Whole thread Raw
In response to Re: New strategies for freezing, advancing relfrozenxid early  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: New strategies for freezing, advancing relfrozenxid early  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Mon, 2022-10-03 at 20:11 -0700, Peter Geoghegan wrote:
> True. Though I think that a strong bias in the direction of advancing
> relfrozenxid by some amount (not necessarily by very many XIDs) still
> makes sense, especially when we're already freezing aggressively.

Take the case where you load a lot of data in one transaction. After
the loading transaction finishes, those new pages will soon be marked
all-visible.

In the future, vacuum runs will have to decide what to do. If a vacuum
decides to do an aggressive scan to freeze all of those pages, it may
be at some unfortunate time and disrupt the workload. But if it skips
them all, then it's just deferring the work until it runs up against
autovacuum_freeze_max_age, which might also be at an unfortunate time.

So how does your patch series handle this case? I assume there's some
mechanism to freeze a moderate number of pages without worrying about
advancing relfrozenxid?

Regards,
    Jeff Davis




pgsql-hackers by date:

Previous
From: Ken Kato
Date:
Subject: Re: Add last_vacuum_index_scans in pg_stat_all_tables
Next
From: Peter Smith
Date:
Subject: Re: GUC tables - use designated initializers