Re: [BUGS] Invalid YAML output from EXPLAIN - Mailing list pgsql-hackers

Florian Weimer wrote:
> It has been claimed before that YAML is a superset of JSON, so why
> can't the YAML folks use the existing JSON output instead?
>   

Because JSON just crosses the line where it feels like there's so much 
markup that people expect a tool is necessary to read it, which has 
always been the issue with XML too--bad human readability.  I was on the 
fence about YAML until I used it for a client issue over the weekend.  I 
was able to hack together a quick tool to work on the issue that parsed 
enough YAML *without using an external library* well enough for my 
purposes in an hour, one that was still far more robust than a similar 
hack trying to read plain old text format for EXPLAIN.  And the client 
was able to follow what was going on as I passed YAML output back and 
forth with them.  Just having every field labeled clearly cut off all 
the usual "which of these is the startup cost again?" questions I'm used 
to getting.

The complaints about YAML taking up too much vertical space are 
understandable, but completely opposite of what I care about.  I can 
e-mail a customer a YAML plan and it will survive to the other side and 
even in a reply back to me.  Whereas any non-trivial text format one is 
guaranteed to utterly destroyed by line wrapping along the way.

I think this thread could use a fresh example to remind anyone who 
hasn't played with the curent YAML format what it looks like.  Here's 
one from a query against the Dell Store 2 database:

EXPLAIN SELECT * FROM customers WHERE customerid>1000 ORDER BY zip;
QUERY PLAN
----------
Sort  (cost=4449.30..4496.80 rows=19000 width=268)  Sort Key: zip  ->  Seq Scan on customers  (cost=0.00..726.00
rows=19000width=268)        Filter: (customerid > 1000)
 

EXPLAIN (FORMAT YAML) SELECT * FROM customers WHERE customerid>1000 
ORDER BY zip;            QUERY PLAN             
-------------------------------------- Plan:                            +    Node Type: Sort                +
StartupCost: 4449.30          +    Total Cost: 4496.80            +    Plan Rows: 19000               +    Plan Width:
268               +    Sort Key:                      +      - zip                        +    Plans:
     +      - Node Type: Seq Scan        +        Parent Relationship: Outer +        Relation Name: customers   +
 Alias: customers           +        Startup Cost: 0.00         +        Total Cost: 726.00         +        Plan Rows:
19000          +        Plan Width: 268            +        Filter: (customerid > 1000)
 

-- 
Greg Smith  2ndQuadrant US  Baltimore, MD
PostgreSQL Training, Services and Support
greg@2ndQuadrant.com   www.2ndQuadrant.us