On Fri, 20 Nov 2020 at 03:54, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> > > So +1 for this idea.
> >
> > Patch to do this attached, for discussion.
>
> Thank you for the patch!
>
> + *
> + * Once we decide to dirty the data block we may as well freeze
> + * any tuples that are visible to all, since the additional
> + * cost of freezing multiple tuples is low.
>
> 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.
The additional cost of freezing is sizeof(xl_heap_freeze_tuple) = 11 bytes
I guess there is some overhead for writing the WAL record itself, the
only question is how much. If that is a concern then we definitely
don't want to do that only when using FAST_FREEZE, since that would
slow it down when we want to speed it up.
I've updated the patch to match your proposal, so we can compare. It
seems a shorter patch.
(This patch is an optimization that is totally independent to the
other proposals on this thread).
--
Simon Riggs http://www.EnterpriseDB.com/
