On Mon, Dec 11, 2017 at 12:07 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Tue, Dec 5, 2017 at 5:50 PM, Thomas Munro <thomas.munro@enterprisedb.com>
> wrote:
>> The problem is that our logic (1) focuses on when we should *start*
>> freezing, not by when we'd like to be finished, and (2) is defined in
>> such a way that many tables are likely to reach the trigger point at
>> the same time.
>
> Isn't this only the case when you have many insert only-tables? Other
> tables are going to be vacuumed for wrap around at the first time they are
> vacuumed (for other reasons) after reaching vacuum_freeze_table_age -
> vacuum_freeze_min_age. That should be pretty well staggered because they
> probably have different update and delete rates. But, having those tables
> locked for an emergency vacuum which is not really an emergency is certainly
> a pain.
Yes. The cases that I have seen were insert-only tables. Perhaps Vik
Fearing's proposal to vacuum INSERT-only tables[1] would have
prevented the problems I saw by introducing variation from the
different INSERT rates. It's quite likely that several tables have
the same freeze age if you created them at the same time when you
created the schema, but it's much less likely that you inserted into
them at exactly the same rate. Even so, wouldn't it be nice to spread
vacuum freeze work out over time as a design goal rather than leaving
it up to chance?
[1] https://commitfest.postgresql.org/11/744/
--
Thomas Munro
http://www.enterprisedb.com
