Re: BASH script for collecting analyze-related info - Mailing list pgsql-performance

From Ken Tanzer
Subject Re: BASH script for collecting analyze-related info
Date
Msg-id CAD3a31X+wj5hjM=_y+Sw=op1t3jkt_4nLudOzeFy97pvMChLKA@mail.gmail.com
Whole thread Raw
In response to BASH script for collecting analyze-related info  (Ken Tanzer <ken.tanzer@gmail.com>)
List pgsql-performance
On Wed, Oct 9, 2013 at 10:39 AM, John Melesky <john.melesky@rentrakmail.com> wrote:
(off-list)
(on-list)
 
I doubt I'm the first to ask, but have you considered putting this up on github (or similar) so others can contribute more easily and keep it up-to-date?

If that's not in the cards, are you opposed to someone else putting it up on github and taking over management of it?

-john


Actually, you definitely were the first to ask.  I'm not opposed to any combination of putting this on github, continuing to work on this script, or having someone else do it.  But before doing so (or to start), let me throw out a few questions:

First and foremost (and primarily directed to people who are kind enough to provide help on this list), is a script like this worthwhile?  Will it help get better problem reports and save back-and-forth time of "please post x, y and z?"  If not, I don't see the point of pursuing this.

If it is worthwhile, what's the best way of going about getting the necessary information?  Parsing the contents of EXPLAIN output that wasn't designed for this purpose seems doable, but clunky at best.  And it doesn't tell you which views are involved.

In an ideal situation, I'd see this being built into postgres, so that you could do something like EXPLAIN [ANALYZE] DESCRIBE ..., and get your descriptions directly as part of the output.  If that is pure fantasy, is there any way to directly identify all the tables, views and indexes that are involved in a query plan?

If no to the above, then parsing the analyze output seems the only option.  I was pondering what language a script to do this should be written in, and I'm thinking that writing it in pgpsql might be the best option, since it would be the most portable and presumably available on all systems.  I haven't fully thought that through, so I'm wondering if anyone sees reasons that wouldn't work, or if some other language would be a better or more natural choice.

Cheers,
Ken
 

--
AGENCY Software  
A data system that puts you in control
100% Free Software
(253) 245-3801

learn more about AGENCY or
follow the discussion.

pgsql-performance by date:

Previous
From: Gavin Wahl
Date:
Subject: Planner Conceptual Error when Joining a Subquery -- Outer Query Condition not Pulled Into Subquery
Next
From: Tom Lane
Date:
Subject: Re: Planner Conceptual Error when Joining a Subquery -- Outer Query Condition not Pulled Into Subquery