From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "Bossart, Nathan" <bossartn(at)amazon(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New vacuum option to do only freezing |
Date: | 2019-01-15 02:23:35 |
Message-ID: | CAD21AoC3c0R2MMej9dV+ejM4o4zCoOphhXrBmfrTEGyERzTJ5w@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Jan 12, 2019 at 3:27 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Fri, Jan 11, 2019 at 1:14 AM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > Attached the updated patch. Please review it.
>
> I'm quite confused by this patch. It seems to me that the easiest way
> to implement this patch would be to (1) make lazy_space_alloc take the
> maxtuples = MaxHeapTuplesPerPage branch when the new option is
> specified, and then (2) forget about them after each page i.e.
>
> if (nindexes == 0 &&
> vacrelstats->num_dead_tuples > 0)
> {
> ...
> }
> else if (skipping index cleanup)
> vacrelstats->num_dead_tuples = 0;
>
> I don't see why it should touch the logic inside lazy_vacuum_page() or
> the decision about whether to truncate.
>
I think that because the tuples that got dead after heap_page_prune()
looked are recorded but not removed without lazy_vacuum_page() we need
to process them in lazy_vacuum_page(). For decision about whether to
truncate we should not change it, so I will fix it. It should be an
another option to control whether to truncate if we want.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Justin Pryzby | 2019-01-15 02:30:22 | Re: unique, partitioned index fails to distinguish index key from INCLUDEd columns |
Previous Message | Andres Freund | 2019-01-15 02:11:30 | Re: strange valgrind failures (again) |