On Fri, Jul 22, 2016 at 12:14 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> On 7/21/16 4:59 PM, Tom Lane wrote:
>>>
>>> > As for function plans, ISTM that could be added to the PL handlers if
>>> > we
>>> > wanted to (allow a function invocation to return an array of explain
>>> > outputs).
>>
>> Where would you put those, particularly for functions executed many
>> times in the query? Would it include sub-functions recursively?
>> I mean, yeah, in principle we could do something roughly like that,
>> but it's not easy and presenting the results intelligibly seems
>> almost impossible.
>
>
> Yeah, it'd certainly need to be handled internally in a
> machine-understandable form that got aggregated before presentation (or with
> non-text output formats we could provide the raw data). Or just punt and
> don't capture the data unless you're using an alternative output format.
I'd imagine the output to just list all "recursive" execution plans
executed probably along with indicators for how much IO and / or CPU
they were responsible for. The "recursive" plans could also be sorted
in decreasing order of total (i.e. across all individual invocations)
time spent so you see the most impacting plan first. All of that would
loose displaying calling relationships at the advantage of a simpler
presentation. I think, the relationship which statement / function
invoked with other could be determined by looking at statements /
functions. And I guess often it will be apparent from names already.
I am wondering what to do if the same statement has multiple execution
plans if that is possible in such a scenario. Present all the plans or
just the one with the highest impact? Show them next to each other so
the user is immediately aware that all these plans originated from the
same piece of SQL?
Kind regards
robert
--
[guy, jim, charlie].each {|him| remember.him do |as, often| as.you_can
- without end}
http://blog.rubybestpractices.com/
