Greg Stark 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 further updates wheneve
On Wed, May 27, 2009 at 1:30 AM, Kevin Grittner
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 literal and feeding it t
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 default.
Sorry to come in on this discussion so late. Just catching up
Robert Haas 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 that
> without furth
On Tue, May 26, 2009 at 5:24 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 26, 2009 at 3:33 PM, Tom Lane 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 behin
Robert Haas writes:
> On Tue, May 26, 2009 at 3:33 PM, Tom Lane 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.
> OK, how about this:
> http:/
On Tue, May 26, 2009 at 3:33 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, May 26, 2009 at 3:20 PM, Tom Lane 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 happ
Robert Haas writes:
> On Tue, May 26, 2009 at 3:20 PM, Tom Lane 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 sure there's a whole lot to hash
On Tue, May 26, 2009 at 3:20 PM, Tom Lane wrote:
> Greg Stark 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 de
On Tue, May 26, 2009 at 3:04 PM, Greg Stark 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 code is basically jus
Greg Stark 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 sign off on, and then worry
(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 t
Hi,
Peter Eisentraut 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, small, and
* 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:
moun...@pumpkin:~/projects/postgresql/PostgreSQL$ a
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 Pos
On Tue, May 26, 2009 at 1:48 PM, Andrew Dunstan 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 Java and
>> oth
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 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 :
Dave Page wrote:
> On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan 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, t
On Tue, May 26, 2009 at 10:36 AM, Magnus Hagander wrote:
> Dave Page wrote:
>> On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan 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
>>> cor
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 p
-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
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 Post
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Tue, May 26, 2009 at 11:15:21AM -0400, Aidan Van Dyk wrote:
> * 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
> > Siz
On Tue, May 26, 2009 at 9:52 AM, Andrew Dunstan 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
> ability to leve
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 othe
Peter Eisentraut 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, obviously th
On May 26, 2009, at 8:46 AM, Greg Stark
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 I also like being able to co
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 formatted
On May 26, 2009, at 8:15 AM, Peter Eisentraut wrote:
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
Robert Haas 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
On Tue, May 26, 2009 at 8:15 AM, Peter Eisentraut 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 parsing the
> cu
Peter Eisentraut wrote:
> On Monday 25 May 2009 18:02:53 Tom Lane wrote:
>> Robert Haas 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 i
On Monday 25 May 2009 18:02:53 Tom Lane wrote:
> Robert Haas 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
> > m
On Mon, May 25, 2009 at 8:03 PM, Tom Lane wrote:
> Greg Stark writes:
>> On Mon, May 25, 2009 at 11:32 PM, Tom Lane 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 w
Greg Stark writes:
> On Mon, May 25, 2009 at 11:32 PM, Tom Lane 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,
On Mon, May 25, 2009 at 11:32 PM, Tom Lane 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 now I'm not see
On Mon, May 25, 2009 at 6:32 PM, Tom Lane wrote:
> Robert Haas 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, i
Robert Haas 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 output, but let's not
On Mon, May 25, 2009 at 11:22 AM, Tom Lane wrote:
> Joshua Tolley 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
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 c
On Mon, May 25, 2009 at 11:22:24AM -0400, Tom Lane wrote:
> Joshua Tolley 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 EXP
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 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 appr
David Fetter wrote:
On Mon, May 25, 2009 at 11:02:53AM -0400, Tom Lane wrote:
Robert Haas 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
On Mon, May 25, 2009 at 11:02:53AM -0400, Tom Lane wrote:
> Robert Haas 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 w
Joshua Tolley 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 going to be a pa
> 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
> forese
On Mon, May 25, 2009 at 10:55:48AM -0400, Tom Lane wrote:
> Joshua Tolley 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
>
Robert Haas 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 create a cottage indus
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
>
Joshua Tolley 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 table-based proposal,
On Mon, May 25, 2009 at 6:24 AM, Dimitri Fontaine
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, possibly with some tools
-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 t
Hi,
After having read all the followups I already received, I prefer to
answer to this particular message.
Robert Haas writes:
> On Sun, May 24, 2009 at 3:09 PM, Tom Lane wrote:
>> On the other side of the coin, I'm strongly against inventing more than
>> one new output format for EXPLAIN, and
2009/5/25 Tom Lane :
> Greg Smith 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 requ
On Sun, May 24, 2009 at 06:53:29PM -0400, Tom Lane wrote:
> Greg Smith 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 f
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 6:05 PM, Greg Smith 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
> actually do the wor
On Sun, May 24, 2009 at 6:53 PM, Tom Lane wrote:
> Greg Smith 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
On Sun, May 24, 2009 at 4:59 PM, Tom Lane wrote:
> Robert Haas writes:
>> On Sun, May 24, 2009 at 3:09 PM, Tom Lane 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 hav
Greg Smith 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, if there's a se
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
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 synt
Robert Haas writes:
> On Sun, May 24, 2009 at 3:09 PM, Tom Lane 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 the old
setting was.
On Sun, May 24, 2009 at 3:09 PM, Tom Lane wrote:
> Robert Haas 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 e
Robert Haas 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' and I want plain
On Sun, May 24, 2009 at 11:57 AM, Andrew Dunstan 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, than parametr
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 par
2009/5/24 Robert Haas :
>>> 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, tha
>> 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 :
> On Sun, May 24, 2009 at 8:44 AM, Dave Page wrote:
>> On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule
>> wrote:
>>> Hello
>>>
>>> why we develop a new syntax?
>>>
>>> we should have a secondary function explain_query(query_string,
>>> option) that returns setof some. Nex
On Sun, May 24, 2009 at 8:44 AM, Dave Page wrote:
> On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule
> 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_qu
On Sun, May 24, 2009 at 12:31 AM, Pavel Stehule 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 statement is
> enou
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
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.
r
74 matches
Mail list logo
