Tom>One concrete objection to the above is it'd obscure hierarchical
relationships in the context tree,
What is the problem with relationships? Context names are aligned as well provided 8192 is justified to 6-7-8-9 (you pick) characters.
Tom>But given the lack of previous complaints
1) Here it is:
The log lists "TopMemoryContext: 136614192 total", so everybody follows "ah, there's 130MiB used" route.
Nobody in the thread mentions 300MiB taken by "ExecutorState: 318758960 total".
It takes just a single pass to compute "total" (and it takes no memory), so it would be much better if "TopMemoryContext: ..." was replaced with
"Total memory used by all contexts is XXX bytes"
Current TopMemoryContext row is extremely misleading.
Note: 100 was invented "at random" in response to "let's not print everything by default". I do agree with having limit by default, however it would be so much better
if it selected the rows to print even at a cost of increased CPU cycles for the print procedure.
For instance: pgjdbc limits to 256 server-prepared statements by default (per backend). That is current "...Stats" would just ignore at least half of the prepared statements.
3) If you care so much on the number of passes (frankly speaking, I think one can easily wait for 5-10 seconds for debugging/troubleshooting stuff),
then aggregate summary can still be computed and printed with no additional passes (and very limited memory) if the tree is printed in "child-parent" order.
That is print "parent context" information after children iteration is done.
PS. SQL text might involve sensitive information (e.g. logins, passwords, personal IDs), so there might be security issues with printing SQL by default.
Vladimir