Re: display of variables in EXPLAIN VERBOSE

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: display of variables in EXPLAIN VERBOSE
Date: 2019-04-22 15:58:13
Message-ID: 15207.1555948693@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> writes:
> I'd vote to make the code match the documentation, but probably
> implement it by adding a new field to ExplainState and just calculate
> what to do once in ExplainQuery() instead of calculating what to do in
> various random places.

Yeah, this is none too consistent:

$ grep -n 'useprefix =' explain.c
2081: useprefix = list_length(es->rtable) > 1;
2151: useprefix = (IsA(planstate->plan, SubqueryScan) ||es->verbose);
2165: useprefix = (list_length(es->rtable) > 1 || es->verbose);
2238: useprefix = (list_length(es->rtable) > 1 || es->verbose);
2377: useprefix = (list_length(es->rtable) > 1 || es->verbose);
2485: useprefix = list_length(es->rtable) > 1;

If we're going to mess with this, I'd also suggest that we not depend on
list_length(es->rtable) per se, as that counts RTEs that may have nothing
to do with the plan. For instance, I've never been very happy about
this behavior:

regression=# create table tt (f1 int, f2 int);
CREATE TABLE
regression=# explain verbose select * from tt;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on public.tt (cost=0.00..32.60 rows=2260 width=8)
Output: f1, f2
(2 rows)

regression=# create view vv as select * from tt;
CREATE VIEW
regression=# explain verbose select * from vv;
QUERY PLAN
-------------------------------------------------------------
Seq Scan on public.tt (cost=0.00..32.60 rows=2260 width=8)
Output: tt.f1, tt.f2
(2 rows)

The reason for the difference is the presence of the view's RTE
in the plan, but why should that affect the printout? Maybe we
could make it depend on the number of RTE names assigned by
select_rtable_names_for_explain, instead.

BTW, now that I look at this, I think the reason why I didn't make
tlist printouts pay attention to VERBOSE for this purpose is that
you don't get them at all if not verbose:

regression=# explain select * from tt;
QUERY PLAN
------------------------------------------------------
Seq Scan on tt (cost=0.00..32.60 rows=2260 width=8)
(1 row)

So if we were to be rigidly consistent with this point of the docs,
there would be no way to see a tlist without variable qualification,
which doesn't really seem that nice.

Alternatively, we could just leave this as-is. I do not think the
quoted doc paragraph was ever meant as an exact specification
of what EXPLAIN VERBOSE does, nor do I believe that making it so
would be helpful.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-04-22 16:04:01 Re: finding changed blocks using WAL scanning
Previous Message Bruce Momjian 2019-04-22 15:50:49 Re: finding changed blocks using WAL scanning