Re: Backend memory dump analysis - Mailing list pgsql-hackers

From Vladimir Sitnikov
Subject Re: Backend memory dump analysis
Date
Msg-id CAB=Je-EnvU5NjppmEmfo6BqtAnaC9kZyhpK0sBWVwQJ2fAX6kg@mail.gmail.com
Whole thread Raw
In response to Re: Backend memory dump analysis  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Backend memory dump analysis  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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".

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

pgsql-hackers by date:

Previous
From: David Fetter
Date:
Subject: Re: Proposal: http2 wire format
Next
From: Tom Lane
Date:
Subject: Re: Backend memory dump analysis