Prev: Processing database query-results piecemeal
Next: WIP patch: reducing overhead for repeat de-TOASTing
From: "Marko Kreen" on 30 Jun 2008 09:39
On 6/30/08, Dean Rasheed <dean_rasheed(a)hotmail.com> wrote:
> This is a small patch I posted a few months back, and then kinda forgot
> about / got distracted with other things.
>
> Is there any interest in this? If so I am willing to put more work into
> it, if people like it or have suggested improvements. Otherwise I'll let it
> drop.

+1 for including it in whatever form. It is useful.

We actually already use in live settings (8.2 / 8,3).

> (The last example shows foo() being called during the planning of this
> query, which explains why it is called twice during the previous execution)
>
> Simon Riggs reviewed this last time and said that what this patch
> currently does is probably not exactly what is wanted for PostgreSQL.
> Possible improvements might be to integrate this with the EXPLAIN
> command (eg. EXPLAIN TRACE query) and have a separate parameter
> (log_explain) for logging purposes.

I don't have strong opinion either way, It seems its more question
on style than any technical details. Just that plain EXPLAN MORE is
not enough, it would bo good have a way to turn it on in global/session
level for all queries.

--
marko

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Alex Hunsaker" on 30 Jun 2008 12:10
On Mon, Jun 30, 2008 at 6:34 AM, Dean Rasheed <dean_rasheed(a)hotmail.com> wrote:
>
> Hi,
>
> This is a small patch I posted a few months back, and then kinda forgot
> about / got distracted with other things.
>
> Is there any interest in this? If so I am willing to put more work into
> it, if people like it or have suggested improvements. Otherwise I'll let it
> drop.
>
> Here's what is does:
>
> As it stands, basically it's just another debug parameter, called
> debug_explain_plan, similar to debug_print_plan, except that the
> output is in the form of EXPLAIN ANALYSE.

<snip>

> Simon Riggs reviewed this last time and said that what this patch
> currently does is probably not exactly what is wanted for PostgreSQL.
> Possible improvements might be to integrate this with the EXPLAIN
> command (eg. EXPLAIN TRACE query) and have a separate parameter
> (log_explain) for logging purposes.
>
> Comments?

Its certainly not useful to *me* in its current form. It would
produce way to much (usless) output. However if it were tied to
log_min_duration_statement so I get auto explains for long running
queries... That would be very useful indeed. Even if it has to
explain everything just to toss out the explain if it did not meet
log_min_duration_statement. Unless I missed something and thats
exactly what it does?

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Dean Rasheed on 2 Jul 2008 15:42

> Its certainly not useful to *me* in its current form. It would
> produce way to much (usless) output. However if it were tied to
> log_min_duration_statement so I get auto explains for long running
> queries... That would be very useful indeed. Even if it has to
> explain everything just to toss out the explain if it did not meet
> log_min_duration_statement. Unless I missed something and thats
> exactly what it does?

Thanks for the feedback. I agree, it does need a way to limit the
output, and target just the slow-running queries.

I also remember now the problem I had last time:- since this debug
output is produced at a lower level than the other statement logging
(so it can explain *all* SQL executed, not just top-level statements), it
is difficult to control using the normal statement logging parameters.

It would be easy to add another parameter, debug_explain_min_duration,
specific to this option, to limit it to slow low-level queries.

This would allow setting debug_explain_min_duration to be smaller than
log_min_duration_statement, which makes sense, since the latter
controls logging of top-level statements which may result in multiple
low-level queries.

Doing it this way would mean instrumenting all queries, but only
explaining the slow ones, when debug_explain_plan is on.
I'll have a play and see how it goes...

Regards, Dean

_________________________________________________________________
Live Search Charades - guess correctly and find hidden videos
http://www.searchcharades.com/
--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: "Alex Hunsaker" on 3 Jul 2008 13:53
On Thu, Jul 3, 2008 at 10:58 AM, Dean Rasheed <dean_rasheed(a)hotmail.com> wrote:
>
> Here is an updated version of the patch, with a debug_explain_min_duration
> parameter to allow explaining of just slow-running queries. I've also incorporated
> a couple of Simon Riggs' suggestions for formatting the output better.
>
> Do I need to post this to -patches, or is that now obsolete?

Yes its obsolete now, instead add it to July's commit fest at
http://wiki.postgresql.org/wiki/CommitFest:July.

--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

From: Simon Riggs on 6 Jul 2008 11:42

On Thu, 2008-07-03 at 16:58 +0000, Dean Rasheed wrote:
> Here is an updated version of the patch

Dean,

I'm getting 4 chunks fail when trying to apply your patch onto CVS HEAD.

I'm sure its just a little bitrot. Can you update the patch please?

Thanks,

--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Training, Services and Support


--
Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

 |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Processing database query-results piecemeal
Next: WIP patch: reducing overhead for repeat de-TOASTing