On Wed, 19 Aug 2020 at 19:22, Julien Rouhaud <rjuju123@gmail.com> wrote:
> Hearing no objection, here's a patch to change the output as suggested by
> Pierre:
>
> =# explain (analyze, buffers) select * from pg_class;
> QUERY PLAN >
> ------------------------------------------------------------------------------------------------------->
> Seq Scan on pg_class (cost=0.00..16.86 rows=386 width=265) (actual time=0.020..0.561 rows=386 loops=1)
> Buffers: shared hit=9 read=4
> Planning:
> Planning Time: 4.345 ms
> Buffers: shared hit=103 read=12
> Execution Time: 1.447 ms
> (6 rows)
I don't really have anything to say about the change in format, but on
looking at the feature, I do find it strange that I need to specify
ANALYZE to get EXPLAIN to output the buffer information for the
planner.
I'd expect that EXPLAIN (BUFFERS) would work just fine, but I get:
ERROR: EXPLAIN option BUFFERS requires ANALYZE
Ths docs [1] also mention this is disallowed per:
"This parameter may only be used when ANALYZE is also enabled."
I just don't agree that it should be. What if I want to get an
indication of why the planner is slow but I don't want to wait for the
query to execute? or don't want to execute it at all, say it's a
DELETE!
It looks like we'd need to make BUFFERS imply SUMMARY, perhaps
something along the lines of what we do now with ANALYZE with:
/* if the summary was not set explicitly, set default value */
es->summary = (summary_set) ? es->summary : es->analyze;
However, I'm not quite sure how we should handle if someone does:
EXPLAIN (BUFFERS on, SUMMARY off). Without the summary, there's no
place to print the buffers, which seems bad as they asked for buffers.
David
[1] https://www.postgresql.org/docs/devel/sql-explain.html
