Re: VACUUM (DISABLE_PAGE_SKIPPING on)

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

On Fri, 20 Nov 2020 at 15:29, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
> Note on heap_prepare_freeze_tuple()'s fifth parameter, it's not valid to
> pass OldestXmin; you need a multixact limit there, not an Xid limit. I
> think the return value of GetOldestMultiXactId is a good choice. AFAICS
> this means that you'll need to add a new output argument to
> vacuum_set_xid_limits (You *could* call GetOldestMultiXactId again, but
> it seems a waste).
>
> Maybe it's time for vacuum_set_xid_limits to have a caller's-stack-
> allocated struct for input and output values, rather than so many
> arguments and output pointers to fill.

The idea was to maximise freezing because we are already dirtying this
data block, so the reasoning doesn't extend directly to multixacts.
Being more active with multixacts could easily cause more churn there.

So I'm changing the patch to only work with Xids not both xids and
multixacts. If this gets committed we can think more about multixacts
and whether to optimize freezing them in the same situation or not.

--
Simon Riggs http://www.EnterpriseDB.com/

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Korotkov 2020-11-29 16:53:44 Re: Improving spin-lock implementation on ARM.
Previous Message Simon Riggs 2020-11-29 16:42:22 Re: VACUUM (DISABLE_PAGE_SKIPPING on)