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 |
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 |