From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Planner debug views |
Date: | 2015-07-29 01:13:08 |
Message-ID: | 8635.1438132388@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com> writes:
> There are still something bothering me: EXPLAIN is a mixed output with
> original text, rows for RelOptInfo, rows for Paths and possible others
> added later. So we have to use 't as text' to receive each line. To do the
> insertion, we have to further decompose each text line into fields, and
> then do the insertion - seems quite involved with plpgsql programming.
Well, that's only true if we don't expend some effort to make it better.
I could imagine, for instance, that if you specify the EXPLAIN option that
turns on this additional output, the output is no longer just a single
"text" column but is multiple columns. Perhaps one column could be a
key indicating what the other column(s) contain.
Another point is that we decided a long time ago that EXPLAIN's plain-text
output format is not intended to be machine-parsable, and so objecting to
a design on the grounds that it makes machine parsing harder is pretty
wrongheaded. I'd think there is plenty of room for dropping in additional
output data in the non-text output formats. That needs some careful
document-schema design effort, for sure, but it doesn't seem like it would
be particularly hard.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2015-07-29 01:24:36 | Re: [PATCH] Reload SSL certificates on SIGHUP |
Previous Message | Tom Lane | 2015-07-29 00:58:19 | Re: Buildfarm TAP testing is useless as currently implemented |