From: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Ildar Musin <i(dot)musin(at)postgrespro(dot)ru>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Failed to request an autovacuum work-item in silence |
Date: | 2018-03-16 00:43:23 |
Message-ID: | CAD21AoB5AgAF8KJQgpnBDe36ZNpw0yYXW43_EJx422jrRzVLFA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 15, 2018 at 7:35 PM, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
> Masahiko Sawada wrote:
>> On Thu, Mar 15, 2018 at 12:06 AM, Alvaro Herrera
>> <alvherre(at)alvh(dot)no-ip(dot)org> wrote:
>
>> > Now I'm wondering what will we tell users to do if they get this message
>> > too frequently. Neither of the obvious options (1. changing the index's
>> > pages_per_range to a larger value; 2. making autovacuum more frequent
>> > somehow) seem terribly useful.
>>
>> Or telling users to call brin_summarize_range() manually?
>
> Yeah, they can do that to fix the situation with each unsummarized
> range, but that won't silence the log message ... oh! Unless you call it
> to summarize the range ahead of time -- I think that should fix it. Is
> that what you were thinking?
>
Yes. Or with this situation since the multiple work-item for the same
index but different block number might be listed the calling
brin_summarize_new_values() manually would rather fix the situation
more properly?
Regards,
--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Tomas Vondra | 2018-03-16 00:46:39 | Re: Parallel Aggregates for string_agg and array_agg |
Previous Message | Michael Paquier | 2018-03-16 00:26:33 | Re: Clarification needed for comment in storage/file/fd.c |