Re: Backend memory dump analysis

Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> writes:
> 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".

If you're interested in capturing memory usage short of an ENOMEM
condition, or reporting the results anywhere but stderr, you're going
to need such a thing anyway. There's a lot of use-cases that
MemoryContextStats() doesn't cover, and can't be made to cover without
breaking its essential requirement to report ENOMEM successfully.

> 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)

Not much. Maybe it's just that I've been looking at the existing output
format for too many years. But given the lack of previous complaints,
I'm disinclined to make large changes in it.

One concrete objection to the above is it'd obscure hierarchical
relationships in the context tree, such as

TopPortalContext: 8192 total in 1 blocks; 7656 free (2 chunks); 536 used
PortalContext: 1024 total in 1 blocks; 584 free (0 chunks); 440 used
ExecutorState: 8192 total in 1 blocks; 2960 free (0 chunks); 5232 used
printtup: 8192 total in 1 blocks; 7936 free (0 chunks); 256 used
ExprContext: 8192 total in 1 blocks; 7656 free (0 chunks); 536 used

regards, tom lane