From: | Michael Paquier <michael(dot)paquier(at)gmail(dot)com> |
---|---|
To: | Jing Wang <jingwangian(at)gmail(dot)com> |
Cc: | Claudio Freire <klaussfreire(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [HACKERS] [PATCH] Vacuum: Update FSM more frequently |
Date: | 2017-11-28 23:26:59 |
Message-ID: | CAB7nPqRjWXUr-8KcPBYpmFJ1N3CRzwDaovqqYoQV7=q2--qtDA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 27, 2017 at 2:39 PM, Jing Wang <jingwangian(at)gmail(dot)com> wrote:
> A few general comments.
>
> + FreeSpaceMapVacuum(onerel, 64);
>
> Just want to know why '64' is used here? It's better to give a description.
>
> + else
> + {
> + newslot = fsm_get_avail(page, 0);
> + }
>
> Since there is only one line in the else the bracket will not be needed. And
> there in one more space ahead of else which should be removed.
>
>
> + if (nindexes == 0 &&
> + (vacuumed_pages_at_fsm_vac - vacuumed_pages) >
> vacuum_fsm_every_pages)
> + {
> + /* Vacuum the Free Space Map */
> + FreeSpaceMapVacuum(onerel, 0);
> + vacuumed_pages_at_fsm_vac = vacuumed_pages;
> + }
>
> vacuumed_pages_at_fsm_vac is initialised with value zero and seems no chance
> to go into the bracket.
The patch presented still applies, and there has been a review two
days ago. This is a short delay to answer for the author, so I am
moving this patch to next CF with the same status of waiting on
author.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2017-11-28 23:42:54 | Re: [HACKERS] PG10 partitioning - odd behavior/possible bug |
Previous Message | Stephen Frost | 2017-11-28 23:26:38 | Re: [HACKERS] postgres_fdw super user checks |