Re: Backend memory dump analysis

Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> writes:
>> While I didn't do anything about it here, I think it'd likely be a
>> good idea for MemoryContextStats printout to truncate the context ID
>> strings at 100 characters or so

> It would be great if there was an option to show full sql.

Well, as I said, you can do anything you want now in an extension.
But we've had complaints specifically about overly-verbose memory maps
getting spewed to the postmaster log --- that's why there's a default
limit to 100 child contexts now. So I think the standard behavior has
to limit the length of the ID printouts.

(I've since updated my draft patch to do that, and also to convert all
ASCII control characters in an ID to spaces, so that the printouts are
back to a single line per context.)

> For instance, current statistics is not sorted (should it be?), so it just
> prints the first 100 items no matter the size of entries.

It's not going to be sorted, because of the concerns around not consuming
extra memory when we are reporting an ENOMEM problem. Again, if you're
writing an extension that's going to capture memory usage in non-emergency
scenarios, you can make it do whatever you like.

> I think it makes sense to move all the numerics to the front, so the
> numbers are located in the more or less the same columns.

I don't agree. Actually the key number is the one that already is printed
first, ie the total space consumed by the context; all the rest is detail.
Very occasionally, you might be interested in spotting contexts that have
a disproportionate amount of free space, but IME that's seldom the main
issue.

There might be an argument for putting the context ID at the end, along
the lines of

PL/pgSQL function: 16384 total in 2 blocks; 6672 free (4 chunks); 9712 used (alter_table_under_transition_tables_upd_func())

or maybe better with a colon instead of parens:

CachedPlan: 8192 total in 4 blocks; 1504 free (0 chunks); 6688 used: SELECT (SELECT COUNT(*) FROM (SELECT * FROM new_test UNION ALL SELECT * FROM new_test) ss)

so that the total is still reasonably prominent --- it's certainly true
that long context IDs are going to make it harder to see that number,
if they're in front. But this doesn't look terribly nice otherwise, so
I'm not sure. Thoughts?

regards, tom lane