On Wed, May 27, 2009 at 1:30 AM, Kevin Grittner
kevin.gritt...@wicourts.gov wrote:
The big plus of the current technique is that it is so convenient to
Ctrl+C something which is running too long, arrow up, hit Home, and
put the EXPLAIN word in front. Turning the query into a character
string
Greg Stark st...@enterprisedb.com wrote:
http://article.gmane.org/gmane.comp.db.postgresql.devel.patches/21614/match=siginfo
It let you hit a control character while the query was running to
view
the explain analyze for the results so far. The query kept running
and
you could request
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
This is all much more complicated than what I proposed, and I fail to
see what it buys us. I'd say that you're just reinforcing the point I
made upthread, which is that insisting that XML is the only
Peter Eisentraut wrote:
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
This is all much more complicated than what I proposed, and I fail to
see what it buys us. I'd say that you're just reinforcing the point I
made upthread, which is that insisting
On Tue, May 26, 2009 at 8:15 AM, Peter Eisentraut pete...@gmx.net wrote:
I think we are going in the wrong direction. No one has said that they want a
machine-readable EXPLAIN format. OK, there are historically about three
people that want one, but they have already solved the problem of
On May 26, 2009, at 8:15 AM, Peter Eisentraut pete...@gmx.net wrote:
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
This is all much more complicated than what I proposed, and I fail
to
see what it buys us. I'd say that you're just reinforcing the
Well I want an SQL query-able format. I also want a way to retrieve
the data for a query run from within an application without disturbing
the application i.e. while still returning the regular result set.
But I also like being able to conveniently run explain and get the
results
On May 26, 2009, at 8:46 AM, Greg Stark greg.st...@enterprisedb.com
wrote:
Well I want an SQL query-able format. I also want a way to retrieve
the data for a query run from within an application without
disturbing the application i.e. while still returning the regular
result set.
But
Peter Eisentraut pete...@gmx.net writes:
I think we are going in the wrong direction. No one has said that
they want a machine-readable EXPLAIN format. OK, there are
historically about three people that want one, but they have already
solved the problem of parsing the current format.
Well,
Tom Lane wrote:
Now there is a third set of desires having to do with being able to do
simple SQL-based analysis of EXPLAIN output. That's the piece I think
we don't have a good handle on. In particular, it's not clear whether
a SQL-friendly output format can be the same as either of the
On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan and...@dunslane.net wrote:
In libxml-enabled builds at least, this could presumably be done fairly
easily via the XML functions, especially if we get XSLT processing into the
core XML functionality as I hope we can do this release. In fact, the
Peter Eisentraut wrote:
On Tuesday 26 May 2009 16:55:55 Dave Page wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
I was actually looking for a C library for JSON (json type for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, May 26, 2009 at 04:36:56PM +0200, Magnus Hagander wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
Yeah, but probably not a huge
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, May 26, 2009 at 11:15:21AM -0400, Aidan Van Dyk wrote:
* to...@tuxteam.de to...@tuxteam.de [090526 11:03]:
...and to put things into perspective:
to...@floh:~$ apt-cache show libxml2 libjson-glib-1.0-0 | grep ^Size
Size: 814356
On Tue, May 26, 2009 at 09:55:55AM -0400, Dave Page wrote:
from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
...and using XML introduces a dependency for those that apps that don't already
use some XML parser. I realize that since the
On Tue, May 26, 2009 at 10:36 AM, Magnus Hagander mag...@hagander.net wrote:
Dave Page wrote:
On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan and...@dunslane.net wrote:
In libxml-enabled builds at least, this could presumably be done fairly
easily via the XML functions, especially if we get
Dave Page wrote:
On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan and...@dunslane.net wrote:
In libxml-enabled builds at least, this could presumably be done fairly
easily via the XML functions, especially if we get XSLT processing into the
core XML functionality as I hope we can do this
On Tuesday 26 May 2009 16:55:55 Dave Page wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
I was actually looking for a C library for JSON (json type for PostgreSQL; you
know it is coming :-)
Robert Haas wrote:
On the other hand, XML can be a really difficult technology to work
with because it doesn't map cleanly to the data structures that most
modern scripting languages (Perl, Python, Ruby, and probably Java and
others) use. As a simple example, if you have a hash like { a = 1,
On Tue, May 26, 2009 at 1:48 PM, Andrew Dunstan and...@dunslane.net wrote:
Robert Haas wrote:
On the other hand, XML can be a really difficult technology to work
with because it doesn't map cleanly to the data structures that most
modern scripting languages (Perl, Python, Ruby, and probably
Peter Eisentraut wrote:
On Tuesday 26 May 2009 16:55:55 Dave Page wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
I was actually looking for a C library for JSON (json type for PostgreSQL;
* to...@tuxteam.de to...@tuxteam.de [090526 11:03]:
...and to put things into perspective:
to...@floh:~$ apt-cache show libxml2 libjson-glib-1.0-0 | grep ^Size
Size: 814356
Size: 33538
And including glib, which does all the work for libjson-glib:
Hi,
Peter Eisentraut pete...@gmx.net writes:
I was actually looking for a C library for JSON (json type for PostgreSQL;
you
know it is coming :-) ), but only found a library tied to glib, which,
considering the experience with libxml, did not excite me. If someone knows
of a different,
(sorry for top posting - stupid apple)
So the real elephant in the room is that the existing explain code is
not really designed to be extensible, configurable, or to be printed
in different formats.
The current code is basically just gobs of text printed by different
routines all over
Greg Stark greg.st...@enterprisedb.com writes:
So the real elephant in the room is that the existing explain code is
not really designed to be extensible, configurable, or to be printed
in different formats.
These are implementation details ;-). Let's get a definition that
everyone can
On Tue, May 26, 2009 at 3:04 PM, Greg Stark greg.st...@enterprisedb.com wrote:
(sorry for top posting - stupid apple)
So the real elephant in the room is that the existing explain code is not
really designed to be extensible, configurable, or to be printed in
different formats.
The current
On Tue, May 26, 2009 at 3:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark greg.st...@enterprisedb.com writes:
So the real elephant in the room is that the existing explain code is
not really designed to be extensible, configurable, or to be printed
in different formats.
These are
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 3:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
These are implementation details ;-). Let's get a definition that
everyone can sign off on, and then worry about what has to be done
to the code to make it happen.
I'm actually not
On Tue, May 26, 2009 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 3:20 PM, Tom Lane t...@sss.pgh.pa.us wrote:
These are implementation details ;-). Let's get a definition that
everyone can sign off on, and then worry about
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I still haven't seen anything but formless handwaving as far as the SQL
table output format goes. For that matter, there's not much more than
handwaving behind the XML meme either.
On Tue, May 26, 2009 at 5:24 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Tue, May 26, 2009 at 3:33 PM, Tom Lane t...@sss.pgh.pa.us wrote:
I still haven't seen anything but formless handwaving as far as the SQL
table output format goes. For that matter,
Sorry to come in on this discussion so late. Just catching up
Robert Haas robertmh...@gmail.com wrote:
Responding to these in bulk, I think that 1, 3, and 4 are pretty
convincing arguments that the SQL-based output format is
underspecified. I hereby promise not to do anything about
Magnus Hagander a écrit :
Dave Page wrote:
I was thinking something similar, but from the pgAdmin perspective. We
already use libxml2, but JSON would introduce another dependency for
us.
Yeah, but probably not a huge one. There is one for wx, but I don't
think it's included by
2009/5/25 Tom Lane t...@sss.pgh.pa.us:
Greg Smith gsm...@gregsmith.com writes:
On Sun, 24 May 2009, Pavel Stehule wrote:
we should have a secondary function explain_query(query_string,
option) that returns setof some.
+1. The incremental approach here should first be adding functions that
Hi,
After having read all the followups I already received, I prefer to
answer to this particular message.
Robert Haas robertmh...@gmail.com writes:
On Sun, May 24, 2009 at 3:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
On the other side of the coin, I'm strongly against inventing more than
one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
[Sent by mistake to Robert Haas only at first try. No cure for fat
fingers, I guess]
On Sun, May 24, 2009 at 04:05:18PM -0400, Robert Haas wrote:
[...]
I think XML output format is a complete distraction from the real
issue here, which is that
On Mon, May 25, 2009 at 6:24 AM, Dimitri Fontaine
dfonta...@hi-media.com wrote:
I think the summary here is to say that we want two modes of operations:
- the current one, which continues to get refinements
- a new one conveying all possible information in machine readable
formats,
Joshua Tolley eggyk...@gmail.com writes:
The Oracle version, as it fills the table of explain results, gives
each number an id and the id of its parent row, which behavior we
could presumably copy. I'm definitely keen to keep a human-readable
EXPLAIN such as we have now, to augment the
On Mon, May 25, 2009 at 07:14:56AM -0400, Robert Haas wrote:
Many people who responded to this
thread were fine with the idea of some sort of options syntax, but we
had at least four different proposals for how to implement it:
Robert Haas: EXPLAIN (foo 'bar', baz 'bletch', ...) query
Pavel
Robert Haas robertmh...@gmail.com writes:
This is all much more complicated than what I proposed, and I fail to
see what it buys us. I'd say that you're just reinforcing the point I
made upthread, which is that insisting that XML is the only way to get
more detailed information will just
On Mon, May 25, 2009 at 10:55:48AM -0400, Tom Lane wrote:
Joshua Tolley eggyk...@gmail.com writes:
The Oracle version, as it fills the table of explain results, gives
each number an id and the id of its parent row, which behavior we
could presumably copy. I'm definitely keen to keep a
The impression I have is that (to misquote Churchill) XML is the worst
option available, except for all the others. We need something that can
represent a fairly complex data structure, easily supports addition or
removal of particular fields in the structure (including fields not
foreseen
Joshua Tolley eggyk...@gmail.com writes:
I'm not sure I see why it would be less flexible. I'm imagining we define some
record type, and a function that returns a set of those records.
I'm unimpressed by the various proposals to change EXPLAIN into a
function. Quoting the command-to-explain is
On Mon, May 25, 2009 at 11:02:53AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
This is all much more complicated than what I proposed, and I fail
to see what it buys us. I'd say that you're just reinforcing the
point I made upthread, which is that insisting that XML is
David Fetter wrote:
On Mon, May 25, 2009 at 11:02:53AM -0400, Tom Lane wrote:
Robert Haas robertmh...@gmail.com writes:
This is all much more complicated than what I proposed, and I fail
to see what it buys us. I'd say that you're just reinforcing the
point I made upthread, which is
On May 25, 2009, at 0:47 , Joshua Tolley wrote:
On Sun, May 24, 2009 at 06:53:29PM -0400, Tom Lane wrote:
Greg Smith gsm...@gregsmith.com writes:
On Sun, 24 May 2009, Pavel Stehule wrote:
we should have a secondary function explain_query(query_string,
option) that returns setof some.
+1.
On Mon, May 25, 2009 at 11:22:24AM -0400, Tom Lane wrote:
Joshua Tolley eggyk...@gmail.com writes:
I'm not sure I see why it would be less flexible. I'm imagining we define
some
record type, and a function that returns a set of those records.
I'm unimpressed by the various proposals to
Hi Tom,
On 05/25/2009 08:04 PM, Tom Raney wrote:
So, why not put ALL interesting data in the EXPLAIN XML feed? I'm not
suggesting for this discussion that we include discarded plans, but that
we include every piece of data that may be of interest to folks building
connecting tools. The parsers
On Mon, May 25, 2009 at 11:22 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Joshua Tolley eggyk...@gmail.com writes:
I'm not sure I see why it would be less flexible. I'm imagining we define
some
record type, and a function that returns a set of those records.
I'm unimpressed by the various
Robert Haas robertmh...@gmail.com writes:
I agree with this, but there is a lot of sentiment (which I share)
that it should be possible to capture EXPLAIN output using subselect
or CTAS syntax, regardless of exactly what that output ends up being.
Well, it should be possible to capture the
On Mon, May 25, 2009 at 6:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I agree with this, but there is a lot of sentiment (which I share)
that it should be possible to capture EXPLAIN output using subselect
or CTAS syntax, regardless of exactly what that
On Mon, May 25, 2009 at 11:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Admittedly this is a bit inconvenient, but the point is that the
functionality does exist. There is no need to have a built-in
version of this function unless we get significant advantages
from having it built-in, and right
Greg Stark st...@enterprisedb.com writes:
On Mon, May 25, 2009 at 11:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Admittedly this is a bit inconvenient, but the point is that the
functionality does exist. There is no need to have a built-in
version of this function unless we get significant
On Mon, May 25, 2009 at 8:03 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Stark st...@enterprisedb.com writes:
On Mon, May 25, 2009 at 11:32 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Admittedly this is a bit inconvenient, but the point is that the
functionality does exist. There is no need to
Hi Robert,
On 05/24/2009 02:47 AM, Robert Haas wrote:
Well, here we are! Yet another thread about some piece of information
that's omitted from EXPLAIN and can't easily be added because there
are a zillion things we want to add to EXPLAIN and it's not OK to bury
the user[1]! I've long been of
On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule pavel.steh...@gmail.com wrote:
Hello
why we develop a new syntax?
we should have a secondary function explain_query(query_string,
option) that returns setof some. Next function should be
explain_query_xml. I thing so for typical use EXPLAIN
On Sun, May 24, 2009 at 8:44 AM, Dave Page dp...@pgadmin.org wrote:
On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
why we develop a new syntax?
we should have a secondary function explain_query(query_string,
option) that returns setof some. Next
2009/5/24 Robert Haas robertmh...@gmail.com:
On Sun, May 24, 2009 at 8:44 AM, Dave Page dp...@pgadmin.org wrote:
On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule pavel.steh...@gmail.com
wrote:
Hello
why we develop a new syntax?
we should have a secondary function
EXPLAIN ('hash_detail', 'on') query...
Oops, I should have written EXPLAIN (hash_detail 'on') query... can't
follow my own syntax.
I am sorry - this is really strange syntax . Who will use this syntax?
For some parser is little bit better function call, than parametrized
statement. Some
2009/5/24 Robert Haas robertmh...@gmail.com:
EXPLAIN ('hash_detail', 'on') query...
Oops, I should have written EXPLAIN (hash_detail 'on') query... can't
follow my own syntax.
I am sorry - this is really strange syntax . Who will use this syntax?
For some parser is little bit better
Robert Haas wrote:
EXPLAIN ('hash_detail', 'on') query...
Oops, I should have written EXPLAIN (hash_detail 'on') query... can't
follow my own syntax.
I am sorry - this is really strange syntax . Who will use this syntax?
For some parser is little bit better function call, than
On Sun, May 24, 2009 at 11:57 AM, Andrew Dunstan and...@dunslane.net wrote:
Oops, I should have written EXPLAIN (hash_detail 'on') query... can't
follow my own syntax.
I am sorry - this is really strange syntax . Who will use this syntax?
For some parser is little bit better function call,
Robert Haas robertmh...@gmail.com writes:
I wouldn't mind having a GUC to set the *default* explain behavior -
but I'd still like to be able to override it for a particular command
if I so choose. And that's not going to be possible with your syntax:
if explain_format is set to 'xml, verbose'
On Sun, May 24, 2009 at 3:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
I wouldn't mind having a GUC to set the *default* explain behavior -
but I'd still like to be able to override it for a particular command
if I so choose. And that's not going to be
Robert Haas robertmh...@gmail.com writes:
On Sun, May 24, 2009 at 3:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You know about SET LOCAL, no? I don't think this argument is very
convincing.
I completely fail to see how that helps me.
Mainly, what it does is avoid having to know exactly what
On Sun, May 24, 2009 at 11:57:13AM -0400, Andrew Dunstan wrote:
Robert Haas wrote:
EXPLAIN ('hash_detail', 'on') query...
Oops, I should have written EXPLAIN (hash_detail 'on') query... can't
follow my own syntax.
I am sorry - this is really strange syntax . Who will use this
On Sun, 24 May 2009, Pavel Stehule wrote:
we should have a secondary function explain_query(query_string,
option) that returns setof some.
+1. The incremental approach here should first be adding functions that
actually do the work required. Then, if there's a set of those that look
to be
Greg Smith gsm...@gregsmith.com writes:
On Sun, 24 May 2009, Pavel Stehule wrote:
we should have a secondary function explain_query(query_string,
option) that returns setof some.
+1. The incremental approach here should first be adding functions that
actually do the work required. Then,
On Sun, May 24, 2009 at 4:59 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Sun, May 24, 2009 at 3:09 PM, Tom Lane t...@sss.pgh.pa.us wrote:
You know about SET LOCAL, no? I don't think this argument is very
convincing.
I completely fail to see how that
On Sun, May 24, 2009 at 6:53 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Greg Smith gsm...@gregsmith.com writes:
On Sun, 24 May 2009, Pavel Stehule wrote:
we should have a secondary function explain_query(query_string,
option) that returns setof some.
+1. The incremental approach here should
On Sun, May 24, 2009 at 6:05 PM, Greg Smith gsm...@gregsmith.com wrote:
On Sun, 24 May 2009, Pavel Stehule wrote:
we should have a secondary function explain_query(query_string,
option) that returns setof some.
+1. The incremental approach here should first be adding functions that
On Sun, 24 May 2009, Tom Lane wrote:
A serious problem with EXPLAIN via a function returning set, or with
putting the result into a table, is that set results are logically
unordered, just as table contents are.
Fair enough; I think Pavel and myself were presuming an implied line
number in
On Sun, May 24, 2009 at 06:53:29PM -0400, Tom Lane wrote:
Greg Smith gsm...@gregsmith.com writes:
On Sun, 24 May 2009, Pavel Stehule wrote:
we should have a secondary function explain_query(query_string,
option) that returns setof some.
+1. The incremental approach here should first be
Well, here we are! Yet another thread about some piece of information
that's omitted from EXPLAIN and can't easily be added because there
are a zillion things we want to add to EXPLAIN and it's not OK to bury
the user[1]! I've long been of the opinion that the right way to fix
this problem is to
Hello
why we develop a new syntax?
we should have a secondary function explain_query(query_string,
option) that returns setof some. Next function should be
explain_query_xml. I thing so for typical use EXPLAIN statement is
enough. And for machine procession some new function should be
perfect.
75 matches
Mail list logo
