Re: [PG13] Planning (time + buffers) data structure in explain plan (format text)
От | David Rowley |
---|---|
Тема | Re: [PG13] Planning (time + buffers) data structure in explain plan (format text) |
Дата | |
Msg-id | CAApHDvr0hMeEDB6HE=GE6vc2kJjCoiWe7z+CVyD9CoAUB+Cpjw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PG13] Planning (time + buffers) data structure in explain plan (format text) (Julien Rouhaud <rjuju123@gmail.com>) |
Ответы |
Re: [PG13] Planning (time + buffers) data structure in explain plan (format text)
Re: [PG13] Planning (time + buffers) data structure in explain plan (format text) |
Список | pgsql-hackers |
On Wed, 19 Aug 2020 at 21:05, Julien Rouhaud <rjuju123@gmail.com> wrote: > > On Wed, Aug 19, 2020 at 08:49:48PM +1200, David Rowley wrote: > > 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? I'd say BUFFERS on, BUFFERS off is contradictory. I don't think BUFFERS, SUMMARY OFF is. It's just that we show the buffer details for the planner in the summary. Since "summary" is not exactly a word that describes what you're asking EXPLAIN to do, I wouldn't blame users if they got confused as to why their BUFFERS on request was not displayed. We do use errors for weird combinations already, e.g: postgres=# explain (timing on) select * from t1 where a > 4000000; ERROR: EXPLAIN option TIMING requires ANALYZE so, maybe we can just error if analyze == off AND buffers == on AND summary == off. We likely should pay attention to analyze there as it seems perfectly fine to EXPLAIN (ANALYZE, BUFFERS, SUMMARY off). We quite often do SUMMARY off for the regression tests... I think that might have been why it was added in the first place. David
В списке pgsql-hackers по дате отправления: