explain output infelicity in psql
in [PgSql]
|
From: Robert Haas on 9 Dec 2009 16:06 On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > > I have just noticed while checking the EXPLAIN YAML patch that the non-text > explain formats are output as a single line with embedded line feeds, while > the text format is delivered as a set of text records, one per line. The > practical effect of this is that psql decorates the non-text format output > with continuation characters: > > andrew=# explain select count(*) from pg_class where relname ~ 'pg_'; > QUERY PLAN > ---------------------------------------------------------------- > Aggregate (cost=9.67..9.68 rows=1 width=0) > -> Seq Scan on pg_class (cost=0.00..9.16 rows=204 width=0) > Filter: (relname ~ 'pg_'::text) > (3 rows) > > Time: 5.813 ms > andrew=# explain (format yaml) select count(*) from pg_class where > relname ~ 'pg_'; > QUERY PLAN > ----------------------------------------- > - Plan: + > Node Type: Aggregate + > Strategy: Plain + > Startup Cost: 9.67 + > Total Cost: 9.68 + > Plan Rows: 1 + > Plan Width: 0 + > Plans: + > - Node Type: Seq Scan + > Parent Relationship: Outer + > Relation Name: pg_class + > Alias: pg_class + > Startup Cost: 0.00 + > Total Cost: 9.16 + > Plan Rows: 204 + > Plan Width: 0 + > Filter: (relname ~ 'pg_'::text) > (1 row) > > Those + chars at the end of the line are ugly, to say the least, and they > make the supposedly machine-readable formats not so machine readable if > anyone wanted to c&p the output into a parser. (I'm mildly surprised this > hasn't been noticed before). > > Maybe we need to teach psql not to do this formatting for EXPLAIN output? Oh, dear. I think that line continuation syntax was recently added - subsequent to the machine-readable EXPLAIN patch. The reason why it's coded to emit everything as a single row is because that will be most convenient for programs that are sucking down this data programatically. Otherwise, they'll have to concatenate all the lines that are returned. And in fact for XML format, it's even worse: the data is returned as type xml, but that obviously won't fly if we return each line as a separate tuple. On first blush, I'm inclined to suggest that the addition of + signs to mark continuation lines is a misfeature. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Andrew Dunstan on 9 Dec 2009 18:41 Robert Haas wrote: > On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: > >> I have just noticed while checking the EXPLAIN YAML patch that the non-text >> explain formats are output as a single line with embedded line feeds, while >> the text format is delivered as a set of text records, one per line. The >> practical effect of this is that psql decorates the non-text format output >> with continuation characters: >> >> [snip] >> Those + chars at the end of the line are ugly, to say the least, and they >> make the supposedly machine-readable formats not so machine readable if >> anyone wanted to c&p the output into a parser. (I'm mildly surprised this >> hasn't been noticed before). >> >> Maybe we need to teach psql not to do this formatting for EXPLAIN output? >> > > Oh, dear. I think that line continuation syntax was recently added - > subsequent to the machine-readable EXPLAIN patch. The reason why it's > coded to emit everything as a single row is because that will be most > convenient for programs that are sucking down this data > programatically. Otherwise, they'll have to concatenate all the lines > that are returned. > > And in fact for XML format, it's even worse: the data is returned as > type xml, but that obviously won't fly if we return each line as a > separate tuple. > > On first blush, I'm inclined to suggest that the addition of + signs > to mark continuation lines is a misfeature. > > > I certainly agree we don't want to break up the non-text formats. A simple if ugly hack would make psql use old-ascii print style (which doesn't use these contionuation chars) if the first attribute in the resultset was named 'QUERY PLAN' If someone has a better suggestion I'm all ears. cheers andrew -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Pavel Stehule on 10 Dec 2009 02:06 2009/12/9 Robert Haas <robertmhaas(a)gmail.com>: > On Wed, Dec 9, 2009 at 2:37 PM, Andrew Dunstan <andrew(a)dunslane.net> wrote: >> >> I have just noticed while checking the EXPLAIN YAML patch that the non-text >> explain formats are output as a single line with embedded line feeds, while >> the text format is delivered as a set of text records, one per line. The >> practical effect of this is that psql decorates the non-text format output >> with continuation characters: >> >>  andrew=# explain select count(*) from pg_class where relname ~ 'pg_'; >>                QUERY PLAN >> ---------------------------------------------------------------- >>   Aggregate  (cost=9.67..9.68 rows=1 width=0) >>    ->  Seq Scan on pg_class  (cost=0.00..9.16 rows=204 width=0) >>       Filter: (relname ~ 'pg_'::text) >>  (3 rows) >> >>  Time: 5.813 ms >>  andrew=# explain (format yaml) select count(*) from pg_class where >>  relname ~ 'pg_'; >>          QUERY PLAN >> ----------------------------------------- >>   - Plan:                + >>     Node Type: Aggregate        + >>     Strategy: Plain           + >>     Startup Cost: 9.67         + >>     Total Cost: 9.68          + >>     Plan Rows: 1            + >>     Plan Width: 0            + >>     Plans:               + >>      - Node Type: Seq Scan       + >>       Parent Relationship: Outer   + >>       Relation Name: pg_class     + >>       Alias: pg_class         + >>       Startup Cost: 0.00       + >>       Total Cost: 9.16        + >>       Plan Rows: 204         + >>       Plan Width: 0          + >>       Filter: (relname ~ 'pg_'::text) >>  (1 row) >> >> Those + chars at the end of the line are ugly, to say the least, and they >> make the supposedly machine-readable formats not so machine readable if >> anyone wanted to c&p the output into a parser. (I'm mildly surprised this >> hasn't been noticed before). >> >> Maybe we need to teach psql not to do this formatting for EXPLAIN output? > > Oh, dear.  I think that line continuation syntax was recently added - > subsequent to the machine-readable EXPLAIN patch.  The reason why it's > coded to emit everything as a single row is because that will be most > convenient for programs that are sucking down this data > programatically.  Otherwise, they'll have to concatenate all the lines > that are returned. > > And in fact for XML format, it's even worse: the data is returned as > type xml, but that obviously won't fly if we return each line as a > separate tuple. > > On first blush, I'm inclined to suggest that the addition of + signs > to mark continuation lines is a misfeature. +1 Pavel > > ...Robert > > -- > Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-hackers > -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Alvaro Herrera on 10 Dec 2009 08:12 Robert Haas escribi�: > On first blush, I'm inclined to suggest that the addition of + signs > to mark continuation lines is a misfeature. -1 EXPLAIN is a special case. IMHO it should be dealt with accordingly. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Roger Leigh on 10 Dec 2009 08:29 On Thu, Dec 10, 2009 at 10:12:32AM -0300, Alvaro Herrera wrote: > Robert Haas escribió: > > > On first blush, I'm inclined to suggest that the addition of + signs > > to mark continuation lines is a misfeature. > > -1 > > EXPLAIN is a special case. IMHO it should be dealt with accordingly. If the formatting code can be taught that it's outputting for explain, we can skip the wrap/newline markup easily. I don't think we necessarily need to fall back to the old-ascii format, we just conditionally disable that specific part. Alternatively, would it make more sense just to add a boolean pset parameter to enable/disable the use of wrap/newline marks? It may be that people may wish to disable it for use cases in addition to EXPLAIN. Regards, Roger -- .''`. Roger Leigh : :' : Debian GNU/Linux http://people.debian.org/~rleigh/ `. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/ `- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
|
Next
|
Last
Pages: 1 2 3 4 5 6 Prev: [HACKERS] explain output infelicity in psql Next: Largeobject Access Controls (r2460) |