Re: VACUUM (DISABLE_PAGE_SKIPPING on)

On 2020-Nov-20, Masahiko Sawada wrote:

> I'm concerned that always freezing all tuples when we're going to make
> the page dirty would affect the existing vacuum workload much. The
> additional cost of freezing multiple tuples would be low but if we
> freeze tuples we would also need to write WAL, which is not negligible
> overhead I guess. In the worst case, if a table has dead tuples on all
> pages we process them, but with this patch, in addition to that, we
> will end up not only freezing all live tuples but also writing
> XLOG_HEAP2_FREEZE_PAGE WAL for all pages. So I think it would be
> better either to freeze all tuples if we find a tuple that needs to be
> frozen or to make this behavior work only if the new VACUUM option is
> specified.

There are two costs associated with this processing. One is dirtying
the page (which means it needs to be written down when evicted), and the
other is to write WAL records for each change. The cost for the latter
is going to be the same in both cases (with this change and without)
because the same WAL will have to be written -- the only difference is
*when* do you pay it. The cost of the former is quite different; with
Simon's patch we dirty the page once, and without the patch we may dirty
it several times before it becomes "stable" and no more writes are done
to it.

(If you have tables whose pages change all the time, there would be no
difference with or without the patch.)

Dirtying the page less times means less full-page images to WAL, too,
which can be significant.