Andres Freund and...@anarazel.de writes:
On 06/16/2009 04:32 PM, Robert Haas wrote:
Note that even in this case we DON'T rely on the ordering of the
nodes. The innerplan nodes have child nodes which contain their
relationship to the parent.
Not in the case of Append nodes, but I fail to
Tom Lane wrote:
Andres Freund and...@anarazel.de writes:
On 06/16/2009 04:32 PM, Robert Haas wrote:
Note that even in this case we DON'T rely on the ordering of the
nodes. The innerplan nodes have child nodes which contain their
relationship to the parent.
Not in the
Andres Freund wrote:
Anyway, I think what this discussion points out is that we actually need
a formal XML Schema for this output.
Agreed.
If helpful I can create a schema for the current format.
That will give us a useful starting point.
cheers
andrew
--
Sent via pgsql-hackers
On Tue, Jun 16, 2009 at 1:53 PM, Andres Freundand...@anarazel.de wrote:
While that also looks sensible the more structured variant makes it easier
to integrate additional stats which may not easily be pressed in the
'attribute' format. As a fastly contrived example you could have io
statistics
Greg Stark gsst...@mit.edu writes:
I'm picturing adding a new tag, such as iostats, or actually I was
thinking of dtrace. If we have separate tags for all the estimates
and actual timings then any tags which come with the iostat or
dtrace option would just get mixed up with the estimates and
Tom Lane wrote:
But I'd be just as happy with a naming convention, like
planner:rowcount versus actual:rowcount, etc. I don't know
enough about XML usage to understand the benefits and costs of
different ways of providing that kind of structure.
FYI, you probably don't want this. the ':'
On Tue, Jun 16, 2009 at 12:04 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Greg Stark gsst...@mit.edu writes:
I'm picturing adding a new tag, such as iostats, or actually I was
thinking of dtrace. If we have separate tags for all the estimates
and actual timings then any tags which come with the
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 16, 2009 at 12:04 PM, Tom Lanet...@sss.pgh.pa.us wrote:
FWIW, I like Greg's idea of subdividing the available data this way.
I like it too, but I'd like to see us come up with a design that
allows it to be used for all of the output
On Tue, Jun 16, 2009 at 1:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 16, 2009 at 12:04 PM, Tom Lanet...@sss.pgh.pa.us wrote:
FWIW, I like Greg's idea of subdividing the available data this way.
I like it too, but I'd like to see us come up
Robert Haas robertmh...@gmail.com writes:
On Tue, Jun 16, 2009 at 1:21 PM, Tom Lanet...@sss.pgh.pa.us wrote:
As a concrete example of what I'm thinking about, I'd hope that PgAdmin
would be able to display a graphical summary of a plan tree, and then
pop up measurements associated with one of
On Tue, Jun 16, 2009 at 2:12 PM, Tom Lanet...@sss.pgh.pa.us wrote:
The main point here is that we have a pretty good idea of what
general-purpose client code is likely to want to do with the data, and
in a lot of cases that does not translate to having to know each node
type explicitly, so
On 06/16/2009 09:51 PM, Robert Haas wrote:
On Tue, Jun 16, 2009 at 2:12 PM, Tom Lanet...@sss.pgh.pa.us wrote:
The main point here is that we have a pretty good idea of what
general-purpose client code is likely to want to do with the data,
and in a lot of cases that does not translate to
I wrote:
On Sun, Jun 14, 2009 at 1:04 PM, Robert Haasrobertmh...@gmail.com wrote:
On Sun, Jun 14, 2009 at 1:02 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 14, 2009 at 11:28 AM, Tom Lanet...@sss.pgh.pa.us wrote:
However, using
Robert Haas robertmh...@gmail.com writes:
Hmm... on further review, I'm thinking this is still a bit wastful,
because we don't really need (I think) to call
TupleDescGetAttInMetadata from begin_tup_output_tupdesc. But I'm not
sure what the best way is to avoid that. Any thoughts?
Er, just
On Mon, Jun 15, 2009 at 9:51 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
Hmm... on further review, I'm thinking this is still a bit wastful,
because we don't really need (I think) to call
TupleDescGetAttInMetadata from begin_tup_output_tupdesc. But I'm not
Robert Haas robertmh...@gmail.com writes:
it looks like I can probably rip that member out of TupOutputState
altogether.
Will update patch. Does this look like what you were thinking otherwise?
Yeah, that's exactly what I was thinking.
regards, tom lane
--
Sent via
On 6/13/09, Bernd Helmle maili...@oopsware.de wrote:
--On 13. Juni 2009 15:01:43 -0400 Robert Haas robertmh...@gmail.com wrote:
Also, the result type of an EXPLAIN (format xml) should be type xml, not
text.
Seems reasonable. I'll see if I can figure out how to do that.
I suppose it's
2009/6/14 Dave Page dp...@pgadmin.org:
On 6/13/09, Bernd Helmle maili...@oopsware.de wrote:
--On 13. Juni 2009 15:01:43 -0400 Robert Haas robertmh...@gmail.com wrote:
Also, the result type of an EXPLAIN (format xml) should be type xml, not
text.
Seems reasonable. I'll see if I can figure
On 6/14/09, Pavel Stehule pavel.steh...@gmail.com wrote:
2009/6/14 Dave Page dp...@pgadmin.org:
On 6/13/09, Bernd Helmle maili...@oopsware.de wrote:
--On 13. Juni 2009 15:01:43 -0400 Robert Haas robertmh...@gmail.com
wrote:
Also, the result type of an EXPLAIN (format xml) should be type
Dave Page wrote:
I thing so using --with-libxml is good idea. Is nonsense repeat some
necessary xml code like xml escaping and similar. And almost all
distributed PostgreSQL binaries are compiled with xml support, so this
cannot do some problems. When somebody compile pg without xml support,
Dave Page dp...@pgadmin.org writes:
On 6/14/09, Pavel Stehule pavel.steh...@gmail.com wrote:
I thing so using --with-libxml is good idea.
That will mean we never get to use XML explain in pgAdmin.
Exactly. We are *not* going to make libxml a required piece of
infrastructure, and that means
Andrew Dunstan and...@dunslane.net writes:
As a matter of curiosity, do we have any idea what platforms don't
support libxml2?
It's only partially about whether libxml2 is portable enough. A person
building Postgres might also have legitimate concerns about how bug-free
and/or secure it is.
Peter Eisentraut pete...@gmx.net writes:
A regression test for EXPLAIN, however, should primarily check whether the
output format is stable. We are planning to offer this as a public
interface,
after all. You could use faked up statistics and all but one or two plan
types turned off,
Robert Haas robertmh...@gmail.com writes:
On Sat, Jun 13, 2009 at 6:40 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I believe we have things set up so that you can still print xml data
without libxml configured in. We'd need to be sure casting to text
works too, but other than that I don't see an
On Sun, Jun 14, 2009 at 11:28 AM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sat, Jun 13, 2009 at 6:40 PM, Tom Lanet...@sss.pgh.pa.us wrote:
I believe we have things set up so that you can still print xml data
without libxml configured in. We'd need to be
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 14, 2009 at 11:28 AM, Tom Lanet...@sss.pgh.pa.us wrote:
However, using BuildTupleFromCStrings is wasteful/stupid for *both*
text and xml output, so it seems like getting rid of it is the thing
to do here.
Makes sense. However, if we just
On Sun, Jun 14, 2009 at 1:02 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 14, 2009 at 11:28 AM, Tom Lanet...@sss.pgh.pa.us wrote:
However, using BuildTupleFromCStrings is wasteful/stupid for *both*
text and xml output, so it seems like getting rid
On Sun, Jun 14, 2009 at 1:04 PM, Robert Haasrobertmh...@gmail.com wrote:
On Sun, Jun 14, 2009 at 1:02 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, Jun 14, 2009 at 11:28 AM, Tom Lanet...@sss.pgh.pa.us wrote:
However, using BuildTupleFromCStrings is
On Saturday 13 June 2009 01:10:06 Robert Haas wrote:
pgexplain, as it happens... I could post some samples of the
output, but it seems like it might be just as well to let those who
are curious try it for themselves. I'd rather get opinions from
people who care enough to download test than
--On 13. Juni 2009 15:01:43 -0400 Robert Haas robertmh...@gmail.com wrote:
Also, the result type of an EXPLAIN (format xml) should be type xml, not
text.
Seems reasonable. I'll see if I can figure out how to do that.
I suppose it's okay then, that the format is not available when the
Bernd Helmle maili...@oopsware.de writes:
--On 13. Juni 2009 15:01:43 -0400 Robert Haas robertmh...@gmail.com wrote:
Also, the result type of an EXPLAIN (format xml) should be type xml, not
text.
Seems reasonable. I'll see if I can figure out how to do that.
I suppose it's okay then, that
On Sat, Jun 13, 2009 at 6:40 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Bernd Helmle maili...@oopsware.de writes:
--On 13. Juni 2009 15:01:43 -0400 Robert Haas robertmh...@gmail.com wrote:
Also, the result type of an EXPLAIN (format xml) should be type xml, not
text.
Seems reasonable. I'll see
Robert Haas robertmh...@gmail.com writes:
In any event, considering that EXPLAIN is a utility statement and
can't be embedded within a query, I'm not sure what benefit we get out
of returning the data as XML rather than text. This doesn't seem
likely to change either, based on Tom's comments
On Sat, Jun 13, 2009 at 7:42 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
In any event, considering that EXPLAIN is a utility statement and
can't be embedded within a query, I'm not sure what benefit we get out
of returning the data as XML rather than text.
On Saturday 13 June 2009 22:01:43 Robert Haas wrote:
* Instead of pgexplain, use explain with an XML namespace
declaration.
Could you specify this a bit further, like write out exactly what you
want it to look like? My XML-fu is not very strong.
Just replace your pgexplain by
explain
On Saturday 13 June 2009 22:01:43 Robert Haas wrote:
I recommend, however, that you think about writing a regression test for
this, so the interfaces are explicit, and those tweaking them in the
future know what they are dealing with.
I would like to have something in this area, but Tom
On Sunday 14 June 2009 07:27:19 Robert Haas wrote:
On Sat, Jun 13, 2009 at 7:42 PM, Tom Lanet...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
In any event, considering that EXPLAIN is a utility statement and
can't be embedded within a query, I'm not sure what benefit we
On 6/11/09 10:15 PM, Robert Haas wrote:
Here we go, XML and JSON output.
You will need to apply explain_refactor-v4.patch and
explain_options-v2.patch first, then apply the two patches attached to
this message.
Wow, cool. Can this work with auto_explain? That's where I see
machine-readable
On Fri, Jun 12, 2009 at 11:47 AM, Josh Berkusj...@agliodbs.com wrote:
On 6/11/09 10:15 PM, Robert Haas wrote:
Here we go, XML and JSON output.
You will need to apply explain_refactor-v4.patch and
explain_options-v2.patch first, then apply the two patches attached to
this message.
Wow,
How would you go about extracting the XML/JSON bits from the rest of
what is in the log file? (apologies if this is a question I should
already know the answer to)
If you do CSV output, it's in a field.
--
Josh Berkus
PostgreSQL Experts Inc.
www.pgexperts.com
--
Sent via pgsql-hackers
Josh Berkus wrote:
How would you go about extracting the XML/JSON bits from the rest of
what is in the log file? (apologies if this is a question I should
already know the answer to)
If you do CSV output, it's in a field.
And even if it's not, a well formed XML document would be fairly
On Fri, Jun 12, 2009 at 5:13 PM, Andrew Dunstanand...@dunslane.net wrote:
Josh Berkus wrote:
How would you go about extracting the XML/JSON bits from the rest of
what is in the log file? (apologies if this is a question I should
already know the answer to)
If you do CSV output, it's in a
On Friday 12 June 2009 08:15:17 Robert Haas wrote:
Here we go, XML and JSON output.
Could you post some examples of how some plans would look in either format?
That would help us judge the particulars.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to
101 - 143 of 143 matches
Mail list logo
