On Fri, 20 Nov 2020 at 03:54, Masahiko Sawada <sawada.m...@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/
one_freeze_then_max_freeze.v6.patch
Description: Binary data
