Re: VACUUM (DISABLE_PAGE_SKIPPING on)

Hi Simon,

On Mon, Nov 30, 2020 at 1:53 AM Simon Riggs <simon(at)2ndquadrant(dot)com> wrote:
>
> 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.
>

You sent in your patch, one_freeze_then_max_freeze.v7.patch to
pgsql-hackers on Nov 30, but you did not post it to the next
CommitFest[1]. If this was intentional, then you need to take no
action. However, if you want your patch to be reviewed as part of the
upcoming CommitFest, then you need to add it yourself before
2021-01-01 AoE[2]. Thanks for your contributions.

Regards,

[1] https://commitfest.postgresql.org/31/
[2] https://en.wikipedia.org/wiki/Anywhere_on_Earth

--
Masahiko Sawada
EnterpriseDB: https://www.enterprisedb.com/