From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Backend memory dump analysis |
Date: | 2018-03-25 17:50:08 |
Message-ID: | CAB=Je-EnvU5NjppmEmfo6BqtAnaC9kZyhpK0sBWVwQJ2fAX6kg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom>Well, as I said, you can do anything you want now in an extension.
That is true. However it basically means "everybody who cares to
troubleshoot the memory use of a production system should install an
extension".
Should
https://wiki.postgresql.org/wiki/Developer_FAQ#Examining_backend_memory_use
provide
a link to the extension then?
Tom>Actually the key number is the one that already is printed
Tom>first, ie the total space consumed by the context
The space used is more important than the context name itself.
What do you think of
8192 (2 blocks) CachedPlan: 1504 free (0 chunks); 6688 used: SELECT
(SELECT COUNT(*) FROM (SELECT * FROM new_test UNION ALL SELECT *
FROM new_test) ss)
?
PS. "1504 free (0 chunks)" reads odd.
Tom>Very occasionally, you might be interested in spotting contexts that
have
Tom>a disproportionate amount of free space, but IME that's seldom the main
Tom>issue.
Fully agree. That is why I suggest "total, used, free" order so it matches
the likelihood of usage.
Vladimir
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-03-25 18:05:26 | Re: Backend memory dump analysis |
Previous Message | David Fetter | 2018-03-25 17:42:49 | Re: Proposal: http2 wire format |