| From: | Ilya Kosmodemiansky <ilya(dot)kosmodemiansky(at)postgresql-consulting(dot)com> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Andres Freund <andres(at)2ndquadrant(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |
| Date: | 2014-10-03 15:56:08 |
| Message-ID: | CAG95seV_9rLBapSD2k9x8=cdVz4UxKi=pxUheoAtY9u2F03TpA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Fri, Oct 3, 2014 at 5:51 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I do think that the instrumentation data gathered by LWLOCK_STATS is
> useful - very useful.
Sure, quite useful.
But how about this comment:
/*
* The LWLock stats will be updated within a critical section, which
* requires allocating new hash entries. Allocations within a critical
* section are normally not allowed because running out of memory would
* lead to a PANIC, but LWLOCK_STATS is debugging code that's not normally
* turned on in production, so that's an acceptable risk. The hash entries
* are small, so the risk of running out of memory is minimal in practice.
*/
> But it does have significant overhead.
I will say that it is a bit more than overhead for production use.
--
Ilya Kosmodemiansky,
PostgreSQL-Consulting.com
tel. +14084142500
cell. +4915144336040
ik(at)postgresql-consulting(dot)com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Alvaro Herrera | 2014-10-03 16:06:33 | Re: Per table autovacuum vacuum cost limit behaviour strange |
| Previous Message | Ilya Kosmodemiansky | 2014-10-03 15:53:59 | Re: Dynamic LWLock tracing via pg_stat_lwlock (proof of concept) |