> -Original Message-
> From: Jim C. Nasby [mailto:[EMAIL PROTECTED]
> Sent: 13 April 2006 01:07
> To: Dave Page; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Get explain output of postgresql in Table
> -Original Message-
> From: Alvaro Herrera [mailto:[EMAIL PROTECTED]
> Sent: 13 April 2006 00:28
> To: Dave Page
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]; pgsql-hackers@postgresql.org
> Subject: Re: [HACKERS] Get explain
On Wed, Apr 12, 2006 at 07:28:25PM -0400, Alvaro Herrera wrote:
> Dave Page escribi?:
>
> > > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > > It would be nice to see the "visual explain" tool that Denis wrote --
> > > > did he finish it? Is it available somewhere? Are there any
> > > > scree
Dave Page escribió:
> > Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > > It would be nice to see the "visual explain" tool that Denis wrote --
> > > did he finish it? Is it available somewhere? Are there any screenshots?
>
> > Red Hat did one of these some years ago:
> > http://sources.redhat.c
On Wed, Apr 12, 2006 at 03:34:05PM -0700, Josh Berkus wrote:
> If we have an XML patch now, I say use it. I know I want it.
Certainly; XML is better than nothing. But since it shouldn't be hard to
add the ability to output a recordset at the same time...
--
Jim C. Nasby, Sr. Engineering Consult
"Jim C. Nasby" <[EMAIL PROTECTED]> writes:
> Having an SQL format would make it easier to allow for a mode that
> captures explain or explain analyze output from every query. Turn that
> mode on, run an application's test suite, and now you have a pretty good
> idea of how all the queries will ru
Jim,
> The list goes on. Like I said, you could do all these things with XML,
> you just couldn't easily do them within the database.
XML --> Table conversion should be relatively easy with PL/Perl, PL/Java,
and/or an external language. Heck, if we could expand our XML tools
(Peter will have
TED]"<[EMAIL PROTECTED]>,
"pgsql-hackers@postgresql.org"
Subject: Re: [HACKERS] Get explain output of postgresql in Tables
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > It would be nice to see the "visual explain" tool that Denis wrote --
> > did
Ühel kenal päeval, K, 2006-04-12 kell 17:42, kirjutas Alvaro Herrera:
> It would be nice to see the "visual explain" tool that Denis wrote --
> did he finish it? Is it available somewhere? Are there any screenshots?
IIRC there is a "visual explain" tool pin pgAdmin III
---
Hannu
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> It would be nice to see the "visual explain" tool that Denis wrote --
> did he finish it? Is it available somewhere? Are there any screenshots?
Red Hat did one of these some years ago:
http://sources.redhat.com/rhdb/visualexplain.html
I don't see a pr
Ühel kenal päeval, K, 2006-04-12 kell 14:38, kirjutas Jim C. Nasby:
> Well, really just about anything you'd want to do with it in an XML
> format. The advantage of SQL is that you can do it within the database,
> and you don't have to worry about having something around that can
> process XML.
>
Hi,
Germán Poó Caamaño escribió:
> We can get the best of both worlds.
>
> For instance, EXPLAIN and EXPLAIN ANALYZE with the usual output; but
> also EXPLAIN XML and EXPLAIN ANALYZE XML with an XML syntax to be
> used by programs.
>
> I have a patch for this behavior, but unfortunately this i
On Wed, 2006-04-12 at 14:38 -0500, Jim C. Nasby wrote:
> On Wed, Apr 12, 2006 at 09:45:41AM -0700, Mischa Sandberg wrote:
> > Jim C. Nasby wrote:
> > >On Wed, Apr 12, 2006 at 04:53:20PM +0200, Thomas Hallgren wrote:
> > >
> > >>
> > >>
> > >>
> > >>
> > >>
> > >
> > >
> > >Well, the downs
On Wed, Apr 12, 2006 at 09:45:41AM -0700, Mischa Sandberg wrote:
> Jim C. Nasby wrote:
> >On Wed, Apr 12, 2006 at 04:53:20PM +0200, Thomas Hallgren wrote:
> >
> >>
> >>
> >>
> >>
> >>
> >
> >
> >Well, the downside is that such a format means explain output is now
> >twice as long. But I'd
Greg Sabino Mullane wrote:
I wonder if it would help much just to change EXPLAIN to indent with
something other than spaces?
I like that. Maybe even decrease the indenting a little more, and compress
some of the inner whitespace (such as the 2 spaces after the operator name)
Might it be wort
Jim C. Nasby wrote:
On Wed, Apr 12, 2006 at 04:53:20PM +0200, Thomas Hallgren wrote:
Well, the downside is that such a format means explain output is now
twice as long. But I'd love to see something like that as an option. I'd
also still like to see an SQL-parseable version as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
> I wonder if it would help much just to change EXPLAIN to indent with
> something other than spaces?
I like that. Maybe even decrease the indenting a little more, and compress
some of the inner whitespace (such as the 2 spaces after the operator na
Ühel kenal päeval, K, 2006-04-12 kell 10:29, kirjutas Jim C. Nasby:
> On Wed, Apr 12, 2006 at 04:53:20PM +0200, Thomas Hallgren wrote:
> >
> >
> >
> >
> >
>
> Well, the downside is that such a format means explain output is now
> twice as long.
You can place end tags differently
On Wed, Apr 12, 2006 at 04:53:20PM +0200, Thomas Hallgren wrote:
>
>
>
>
>
Well, the downside is that such a format means explain output is now
twice as long. But I'd love to see something like that as an option. I'd
also still like to see an SQL-parseable version as well, since I
Richard Huxton wrote:
Tom Lane wrote:
I dislike the thought of encouraging people to post stuff in a
not-easily-readable format. They won't do it anyway, if it's not
default; look how we still can't get people to send EXPLAIN ANALYZE
output the first time.
It certainly needs to be one format
Tom Lane wrote:
I dislike the thought of encouraging people to post stuff in a
not-easily-readable format. They won't do it anyway, if it's not
default; look how we still can't get people to send EXPLAIN ANALYZE
output the first time.
It certainly needs to be one format for both purposes.
O
Richard Huxton writes:
> Jim C. Nasby wrote:
>> Actually, I've been wondering about better ways to handle this. One
>> thought is to come up with a non-human readable format that could easily
>> be cut and pasted into a website that would then provide something easy
>> to understand. Ideally that
Jim C. Nasby wrote:
On Mon, Apr 10, 2006 at 10:44:15AM +0100, Richard Huxton wrote:
Bruce Momjian wrote:
* Allow EXPLAIN output to be more easily processed by scripts
Can I request an extension/additional point?
* Design EXPLAIN output to survive cut & paste on mailing-lists
Being ab
On Mon, Apr 10, 2006 at 10:44:15AM +0100, Richard Huxton wrote:
> Bruce Momjian wrote:
> >
> > * Allow EXPLAIN output to be more easily processed by scripts
>
> Can I request an extension/additional point?
> * Design EXPLAIN output to survive cut & paste on mailing-lists
>
> Being able to pa
Bruce Momjian wrote:
* Allow EXPLAIN output to be more easily processed by scripts
Can I request an extension/additional point?
* Design EXPLAIN output to survive cut & paste on mailing-lists
Being able to paste into a web-form and get something readable formatted
back would be very
Jim C. Nasby wrote:
> On Fri, Mar 24, 2006 at 07:54:09AM +0900, Satoshi Nagayasu wrote:
> > Jim C. Nasby wrote:
> > > Structure for the human-consumable output or for something that would be
> > > machine-parsed? ISTM it would be best to keep the current output as-is,
> > > and provide some other m
On Fri, Mar 24, 2006 at 07:54:09AM +0900, Satoshi Nagayasu wrote:
> Jim C. Nasby wrote:
> > Structure for the human-consumable output or for something that would be
> > machine-parsed? ISTM it would be best to keep the current output as-is,
> > and provide some other means for producing machine-fri
Alvaro Herrera wrote:
> Satoshi Nagayasu wrote:
>
>>Jim C. Nasby wrote:
>>
>>>Structure for the human-consumable output or for something that would be
>>>machine-parsed? ISTM it would be best to keep the current output as-is,
>>>and provide some other means for producing machine-friendly output,
>
Satoshi Nagayasu wrote:
> Jim C. Nasby wrote:
> > Structure for the human-consumable output or for something that would be
> > machine-parsed? ISTM it would be best to keep the current output as-is,
> > and provide some other means for producing machine-friendly output,
> > presumably in a table fo
Jim C. Nasby wrote:
> Structure for the human-consumable output or for something that would be
> machine-parsed? ISTM it would be best to keep the current output as-is,
> and provide some other means for producing machine-friendly output,
> presumably in a table format.
How about (well-formed) XML
On Thu, Mar 23, 2006 at 12:39:52AM -0500, Tom Lane wrote:
> "Akshat Nair" <[EMAIL PROTECTED]> writes:
> > Can I get the grammar for the explain output?
>
> There isn't one, it's just text and subject to change at a moment's
> notice :-(. The past proposals that we format it a bit more rigidly
> h
"Akshat Nair" <[EMAIL PROTECTED]> writes:
> Can I get the grammar for the explain output?
There isn't one, it's just text and subject to change at a moment's
notice :-(. The past proposals that we format it a bit more rigidly
have so far foundered for lack of a workable definition of what the
str
HiI read a post in the archives saying about storing explain output directly into tables. Is this feature present in postgres now??I have a software in which I need to display the explain output in a Tree format, for which I need to parse the textual plan and get the relvant information.
I have a p
33 matches
Mail list logo
