Re: Seeing execution plan of foreign key constraint check?

public inbox for [email protected]  
help / color / mirror / Atom feed

From: Robert Klemme <[email protected]>
To: Jim Nasby <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: pgsql-performance <[email protected]>
Subject: Re: Seeing execution plan of foreign key constraint check?
Date: Fri, 22 Jul 2016 10:37:20 +0200
Message-ID: <CAM9pMnNKo6w_drc-xCjo=V-JT-z1y607nXxRfit6gG2LuBQAJg@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <CAM9pMnPs3Jtw9nT7m9E7eH2E3xiExSR6mjmFQrZzoL__hwWxQQ@mail.gmail.com>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
List-Unsubscribe:  <mailto:[email protected]?body=unsub%20pgsql-performance>

On Fri, Jul 22, 2016 at 12:14 AM, Jim Nasby <[email protected]> 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/

-- 
Sent via pgsql-performance mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: Seeing execution plan of foreign key constraint check?
  In-Reply-To: <CAM9pMnNKo6w_drc-xCjo=V-JT-z1y607nXxRfit6gG2LuBQAJg@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox