On Wed, Aug 19, 2020 at 08:49:48PM +1200, David Rowley wrote: > On Wed, 19 Aug 2020 at 19:22, Julien Rouhaud <rjuju...@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!
I quite agree, this restriction is unhelpful since we have planning buffer information. > > It looks like we'd need to make BUFFERS imply SUMMARY +1 > > 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. But this won't be as much a problem if ANALYZE is asked, and having different behaviors isn't appealing. So maybe it's better to let people get what they asked for even if that's contradictory?
