Re: Planner debug views

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

In response to

Responses

Browse pgsql-hackers by date

  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