Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Once you have an XML plan what can you do with it? All you can do is parse it
>> into constituent bits and display it. You cant do any sort of comparison
>> between plans, aggregate results, search for plans matching constraints, etc.
>
On Wed, 2007-06-13 at 14:01 -0400, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Arguably this is a bug if it's causing pg_admin difficulties in parsing the
> > output. Even for a user in an environment where, for example, he has several
> > identical schemas and may be accidental
"Tom Lane" <[EMAIL PROTECTED]> writes:
>> Attached is a small patch which adds this conditionally on a guc that
>> pg_admin or other GUI tools could set, leaving it unchanged for users.
>
> That makes things *worse* not better, since now tools would have to
> deal with both possibilities.
I was t
On 6/13/07, Gregory Stark <[EMAIL PROTECTED]> wrote:
I'm not a fan either so perhaps I'm biased, but this seems like a good example
of where it would be an *awful* idea.
Once you have an XML plan what can you do with it? All you can do is parse it
into constituent bits and display it.
"...and
Gregory Stark <[EMAIL PROTECTED]> writes:
> Once you have an XML plan what can you do with it? All you can do is parse it
> into constituent bits and display it. You cant do any sort of comparison
> between plans, aggregate results, search for plans matching constraints, etc.
Sure you can, just no
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
I agree. XML seems like a fairly natural fit for this. Just as people should
not try to shoehorn everything into XML, neither should they try to shoehorn
everything into a relational format either.
Now all we need is an XML sche
Gregory Stark wrote:
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
I agree. XML seems like a fairly natural fit for this. Just as people should
not try to shoehorn everything into XML, neither should they try to shoehorn
everything into a relational format either.
Now all we need is an XML sch
Gregory Stark <[EMAIL PROTECTED]> writes:
> Arguably this is a bug if it's causing pg_admin difficulties in parsing the
> output. Even for a user in an environment where, for example, he has several
> identical schemas and may be accidentally getting a different table than he's
> expecting the curr
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
> And you stick them in a well-defined XML format (or another
> format if you happen to hate XML) where the client-side program can easily
> parse out whatever it needs. It's also future-proof - if you add a new
> field somewhere, the client pro
"Joshua D. Drake" <[EMAIL PROTECTED]> writes:
>> I agree. XML seems like a fairly natural fit for this. Just as people should
>> not try to shoehorn everything into XML, neither should they try to shoehorn
>> everything into a relational format either.
>>
>> Now all we need is an XML schema for it
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Dave Page <[EMAIL PROTECTED]> writes:
>> Looking to fix this, a comment in src/backend/commands/explain.c
>> indicates that this is intentional:
>
> Quite.
>
>> Anyone know why?
>
> As already noted, it'd usually be clutter in lines that are too long
> alr
Tom Lane wrote:
Dave Page <[EMAIL PROTECTED]> writes:
Looking to fix this, a comment in src/backend/commands/explain.c
indicates that this is intentional:
Quite.
Anyone know why?
As already noted, it'd usually be clutter in lines that are too long
already. Also, conditionally adding a sch
Andrew Dunstan wrote:
Tom Lane wrote:
I agree with the idea of having an option to get EXPLAIN's output in
an entirely different, more machine-readable format. Not wedded to
XML, but I fear that a pure relational structure might be too strict ---
there's a lot of variability in the entries al
> > BTW can I bug you to add the Message-Ids in the messages as displayed in
> > our archives?
> That said, you can get the message-id if you do a view-source. It's in a
> comment at the beginning of the page.
I hadn't seen that before...
2 "bookmarklets" I find useful and have in my "Personal
Tom Lane wrote:
I agree with the idea of having an option to get EXPLAIN's output in
an entirely different, more machine-readable format. Not wedded to
XML, but I fear that a pure relational structure might be too strict ---
there's a lot of variability in the entries already. XML also could
d
Tom Lane wrote:
I agree with the idea of having an option to get EXPLAIN's output in
an entirely different, more machine-readable format. Not wedded to
XML, but I fear that a pure relational structure might be too strict ---
there's a lot of variability in the entries already. XML also could
Tom Lane wrote:
As already noted, it'd usually be clutter in lines that are too long
already. Also, conditionally adding a schema name isn't very good
because it makes life even more complicated for programs that are
parsing EXPLAIN output (yes, there are some).
Well, yes - that's precisely wh
"Magnus Hagander" <[EMAIL PROTECTED]> writes:
> Assuming you can actually *represent* the whole plan as tables, that would
> of course work fine. But I assume you mean "virtual tables"?
Are you saying there are data structures relational databases aren't good at
representing?
In Oracle you had
"Josh Tolley" <[EMAIL PROTECTED]> writes:
> On a different sideline based on the original note of this thread,
> much as EXPLAIN doesn't include the schema, \d doesn't include the
> schema to describe INHERIT relationships in 8.2.4. If you have two
> tables called PARENT, in two different schemas,
Magnus Hagander wrote:
Something worth doing? Not to replace the current explain output, but as a
second option (EXPLAIN XML whatever)?
Yeah, thats been mentioned before. I was looking to bring it up for 8.4.
/D
---(end of broadcast)---
TIP 1:
On 6/13/07, Heikki Linnakangas <[EMAIL PROTECTED]> wrote:
Magnus Hagander wrote:
> On Wed, Jun 13, 2007 at 02:02:24PM +0100, Heikki Linnakangas wrote:
>> DB2 has the concept of "explain tables". Explain output is written to
>> tables, which tools query and pretty print the output. I like that ide
On Wed, Jun 13, 2007 at 09:55:19AM -0400, Alvaro Herrera wrote:
> Magnus Hagander wrote:
> > On Wed, Jun 13, 2007 at 08:47:30AM -0400, Alvaro Herrera wrote:
> > > Magnus Hagander wrote:
> > >
> > > > Just to open a whole new can of worms ;-)
> > > >
> > > > I read an article a couple of days ago
Dave Page <[EMAIL PROTECTED]> writes:
> Looking to fix this, a comment in src/backend/commands/explain.c
> indicates that this is intentional:
Quite.
> Anyone know why?
As already noted, it'd usually be clutter in lines that are too long
already. Also, conditionally adding a schema name isn't v
* Alvaro Herrera <[EMAIL PROTECTED]> [070613 09:58]:
> BTW can I bug you to add the Message-Ids in the messages as displayed in
> our archives?
Yes! Yes! Yes! Pretty please!
--
Aidan Van Dyk Create like a god,
[EMAIL PROTECTED]
Magnus Hagander wrote:
> On Wed, Jun 13, 2007 at 08:47:30AM -0400, Alvaro Herrera wrote:
> > Magnus Hagander wrote:
> >
> > > Just to open a whole new can of worms ;-)
> > >
> > > I read an article a couple of days ago about the "machine readable
> > > showplan
> > > output" in SQL Server 2005 (
Magnus Hagander wrote:
On Wed, Jun 13, 2007 at 02:02:24PM +0100, Heikki Linnakangas wrote:
DB2 has the concept of "explain tables". Explain output is written to
tables, which tools query and pretty print the output. I like that idea
in principle. PostgreSQL is a relational database, so having t
On Wed, Jun 13, 2007 at 02:02:24PM +0100, Heikki Linnakangas wrote:
> Magnus Hagander wrote:
> >On Wed, Jun 13, 2007 at 01:20:25PM +0100, Dave Page wrote:
> Just adding the schema name seems the most sensible and usable option -
> not to mention the easiest!
> >>>While completely ignoring
* Heikki Linnakangas ([EMAIL PROTECTED]) wrote:
> >Something worth doing? Not to replace the current explain output, but as a
> >second option (EXPLAIN XML whatever)?
>
> I agree it would be nice to have machine readable explain output.
Seconded here, I'd much rather see this as a seperate option
Magnus Hagander wrote:
On Wed, Jun 13, 2007 at 01:20:25PM +0100, Dave Page wrote:
Just adding the schema name seems the most sensible and usable option -
not to mention the easiest!
While completely ignoring the current behaviour and likely the reason
it's done the way it is now... explain out
Something worth doing? Not to replace the current explain output, but as a
second option (EXPLAIN XML whatever)?
//Magnus
It's good idea. Similar situation is in stack trace output.
Pavel
---(end of broadcast)---
TIP 4: Have you searched our l
On Wed, Jun 13, 2007 at 08:47:30AM -0400, Alvaro Herrera wrote:
> Magnus Hagander wrote:
>
> > Just to open a whole new can of worms ;-)
> >
> > I read an article a couple of days ago about the "machine readable showplan
> > output" in SQL Server 2005 (basically, it's EXPLAIN output but in XML
>
Magnus Hagander wrote:
> Just to open a whole new can of worms ;-)
>
> I read an article a couple of days ago about the "machine readable showplan
> output" in SQL Server 2005 (basically, it's EXPLAIN output but in XML
> format). It does make a lot of sense if yourp rimary interface is !=
> comma
On Wed, Jun 13, 2007 at 01:20:25PM +0100, Dave Page wrote:
> >>Just adding the schema name seems the most sensible and usable option -
> >>not to mention the easiest!
> >
> >While completely ignoring the current behaviour and likely the reason
> >it's done the way it is now... explain output was,
Stephen Frost wrote:
* Dave Page ([EMAIL PROTECTED]) wrote:
/* We only show the rel name, not schema name */
relname = get_rel_name(rte->relid);
Anyone know why? This seems like a bug to me given the ambiguity of
possible output.
I'd assume it's to keep the explain output smaller with the
exp
Stephen Frost wrote:
Indeed, if you're not constructing the queries that would make things
somewhat difficult. Then again, parsing the explain output seems like
it's going to be rather difficult itself anyway.
Well, we do that anyway - and just grabbing the base table names isn't
too hard.
* Dave Page ([EMAIL PROTECTED]) wrote:
> Stephen Frost wrote:
> >In terms of behaviour changes, I think it'd be nice to show the schema
> >name when necessary but otherwise don't, ala how '\d ' works.
>
> In my case that would be awkward as pgAdmin would then need to try to
> work out what the ac
Stephen Frost wrote:
* Dave Page ([EMAIL PROTECTED]) wrote:
/* We only show the rel name, not schema name */
relname = get_rel_name(rte->relid);
Anyone know why? This seems like a bug to me given the ambiguity of
possible output.
I'd assume it's to keep the explain output smaller with the
exp
* Dave Page ([EMAIL PROTECTED]) wrote:
> /* We only show the rel name, not schema name */
> relname = get_rel_name(rte->relid);
>
> Anyone know why? This seems like a bug to me given the ambiguity of
> possible output.
I'd assume it's to keep the explain output smaller with the
expectation/assump
38 matches
Mail list logo
