Re: VACUUM (DISABLE_PAGE_SKIPPING on)

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: VACUUM (DISABLE_PAGE_SKIPPING on)
Date: 2020-11-20 11:15:36
Message-ID: CANP8+jLVkOam4NvZZ0eHFnaKTJNRMT1xqqChAzE2CYLJjxhN3w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 20 Nov 2020 at 03:54, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)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/

Attachment Content-Type Size
one_freeze_then_max_freeze.v6.patch application/octet-stream 2.5 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-11-20 11:16:42 Re: Asynchronous Append on postgres_fdw nodes.
Previous Message Bharath Rupireddy 2020-11-20 10:33:50 Re: Use standard SIGHUP and SIGTERM handlers in autoprewarm module