On Thu, Jan 25, 2018 at 10:41 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Thu, Jan 25, 2018 at 12:14 AM, Fabrízio de Royes Mello
> <fabriziomello@gmail.com> wrote:
>>
>>
>> On Wed, Jan 24, 2018 at 12:31 PM, Fabrízio de Royes Mello
>> <fabriziomello@gmail.com> wrote:
>>>
>>>
>>>
>>> On Tue, Jan 23, 2018 at 11:44 PM, Masahiko Sawada <sawada.mshk@gmail.com>
>>> wrote:
>>> >
>>> > On Tue, Jan 23, 2018 at 8:03 PM, Fabrízio de Royes Mello
>>> > <fabriziomello@gmail.com> wrote:
>>> > >
>>> > > Em ter, 23 de jan de 2018 às 03:36, Masahiko Sawada
>>> > > <sawada.mshk@gmail.com>
>>> > > escreveu:
>>> > >>
>>> > >> Hi all,
>>> > >>
>>> > >> While reading the code, I realized that the requesting an autovacuum
>>> > >> work-item could fail in silence if work-item array is full. So the
>>> > >> users cannot realize that work-item is never performed.
>>> > >> AutoVacuumRequestWork() seems to behave so from the initial
>>> > >> implementation but is there any reason of such behavior? It seems to
>>> > >> me that it can be a problem even now that there is only one kind of
>>> > >> work-item. Attached patch for fixing it.
>>> > >
>>> > >
>>> > > Seems reasonable but maybe you can use the word "worker" instead of
>>> > > "work
>>> > > item" for report message.
>>> > >
>>> >
>>> > Thank you for the comment.
>>> > Or can we use the word "work-item" since the commit log and source
>>> > code use this word?
>>> >
>>>
>>> You're correct, I misunderstood it thinking about autovacuum workers and
>>> not the internal workitem array.
>>>
>>> As NUM_WORKITEMS is fixed in 256 we don't have any real feedback if in a
>>> real workload this can send a lot of messages to log, so:
>>> 1) maybe invent a new GUC to control if we need or not to send this info
>>> to log
>>> 2) change elevel for DEBUG1
>>>
>
> Hmm, I'd rather think to log the message at LOG level and to have a
> new GUC to control the size of maximum of work-items array . I think
> we should always notify users that work-item couldn't get added
> because it can become a potential performance problem. Also it might
> lead other problems once we have other types of work-item. In the log
> message, we can hint for user that you might want to increase maximum
> of work-items array.
>
>>
>> Looking better for the autovacuum code your patch will work just for BRIN
>> request "brin_summarize_range", correct?
>>
>
> Correct.
>
I've added this to next CF so as not to forget.
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
