Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Date
Msg-id CAD21AoAXW48oHU9JG_tMxkDGeTf-qKP4yt-2moU+5AnAU5xaLQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers
On Mon, Mar 5, 2018 at 10:21 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Fri, Mar 2, 2018 at 10:50 PM, Claudio Freire <klaussfreire@gmail.com> wrote:
>> On Fri, Mar 2, 2018 at 10:47 AM, Claudio Freire <klaussfreire@gmail.com> wrote:
>>> On Fri, Mar 2, 2018 at 7:38 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>>> Thank you for updating the patches!
>>>>
>>>> +/*
>>>> + * When a table has no indexes, vacuum the FSM at most every this
>>>> + * many dirty pages. With a default page size of 8kb, this value
>>>> + * basically means 8GB of dirtied pages.
>>>> + */
>>>> +#define VACUUM_FSM_EVERY_PAGES 1048576
>>>>
>>>> Is it better if we vacuum fsm every 8GB regardless of the block size?
>>>> Because an installation that uses >8GB block size is likely to have
>>>> the pages less than what an 8GB block size installation has, the
>>>> current patch might lead to delay fsm vacuum. What do you think? If
>>>> it's better, we can define it as follows.
>>>>
>>>> #define VACUUM_FSM_EVERY_PAGES ((8 * 1024 * 1024) / BLCKSZ)
>>>
>>> I honestly don't know. I've never tweaked page size, and know nobody
>>> that did, so I have no experience with those installations.
>>>
>>> Lets go with your proposal.
>>>
>>>>
>>>> --
>>>> @@ -470,7 +484,9 @@ lazy_scan_heap(Relation onerel, int options,
>>>> LVRelStats *vacrelstats,
>>>>      TransactionId relfrozenxid = onerel->rd_rel->relfrozenxid;
>>>>      TransactionId relminmxid = onerel->rd_rel->relminmxid;
>>>>      BlockNumber empty_pages,
>>>> -                vacuumed_pages;
>>>> +                vacuumed_pages,
>>>> +                fsm_updated_pages,
>>>> +                vacuum_fsm_every_pages;
>>>>      double        num_tuples,
>>>>                  tups_vacuumed,
>>>>                  nkeep,
>>>>
>>>> Regarding fsm_updated_pages variable name, I think it's better to be
>>>> freespace_updated_pages because we actually counts the page updated
>>>> its freespace, not fsm.
>>>
>>> Good point.
>>>
>>> New version attached.
>>
>> Sorry, forgot to actually squash. Now the real new version is attached.
>
> Thank you for updating. I think the patches has enough discussion and
> quality, so can go to the committer's review. I've marked them as
> Ready for Committer.
>

Oops, the following comment needs to be updated. Since it would be
better to defer decision of this behavior to committers I'll keep the
status of this patch as Ready for Committer behavior.

+/*
+ * When a table has no indexes, vacuum the FSM at most every this
+ * many dirty pages. With a default page size of 8kb, this value
+ * basically means 8GB of dirtied pages.
+ */
+#define VACUUM_FSM_EVERY_PAGES ((8 * 1024 * 1024) / BLCKSZ)
+

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center


pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently
Next
From: Michael Paquier
Date:
Subject: Re: [HACKERS] Support for Secure Transport SSL library on macOS asOpenSSL alternative