From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Vladimir Borodin <root(at)simply(dot)name>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Background Processes and reporting |
Date: | 2016-03-12 11:08:12 |
Message-ID: | CAA4eK1KMrRRzVX7C4xdyvz53jJeppgLLNyxMyz9-y1OSgMrwVQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sat, Mar 12, 2016 at 2:38 PM, Alexander Korotkov <
a(dot)korotkov(at)postgrespro(dot)ru> wrote:
>
> On Sat, Mar 12, 2016 at 2:45 AM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>>
>>
>> I think I agree with Robert here. Providing hooks into very low level
>> places tends to lead to problems in my experience; tight control over
>> what happens is often important - I certainly don't want any external
>> code to run while we're waiting for an lwlock.
>
>
> So, I get following.
>
> 1) Detailed wait monitoring might cause high overhead on some systems.
> 2) We want wait monitoring to be always on. And we don't want options to
enable additional features of wait monitoring.
>
I am not able to see how any of above comments indicate that wait
monitoring need to be always on, why can't we consider to be off by default
especially for events like timing calculations where we suspect to have
some performance penalty and during development if it is proven that none
of the additional wait events cause any overhead, then we can keep them on
by default.
> 3) We don't want hook of wait events to be exposed.
>
> Can I conclude that we reject detailed wait monitoring by design?
>
I don't think so.
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Salvador Fandiño | 2016-03-12 11:59:16 | Re: Saving SRF context |
Previous Message | Oleg Bartunov | 2016-03-12 11:05:47 | Re: Background Processes and reporting |