On 2024/12/14 0:59, Michael Christofides wrote:
> > I've pushed the main patch.
>
> Woohoo! And thank you. I've already seen quite a lot of positivity around the commit on Twitter[1][2][3].
>
> > I'm not planning on pushing the auto_explain.log_buffers default change unless there's a bit more discussion about
it.
>
> Much like Guillaume, I'd also be in favour of 0002, but it's nowhere near as important to me. I think most people
considerthe parameters far more when setting up auto_explain, so I believe far fewer omit buffers by mistake. Also,
mostcloud providers don't ship with auto_explain on, and the only one I know of that does[4], ships with log_buffers on
too.On the plus side, it would be nice to be consistent. But on the downside, it might add a little extra overhead for
folkswho run auto_explain with log_analyze on, and who opted not to set log_buffers and upgrade without setting it to
offexplicitly. I am still in favour of the 0002 patch being applied, to avoid confusion and maximise the chance people
thatdon't know about buffers still get them in their plans.
I agree with changing the default value of auto_explain.log_buffers to true.
I think that users who know EXPLAIN ANALYZE includes buffers info in
the result by default since v18 would expect the buffer info also to
be included in auto_explain output as long as log_analyze is enabled.
So setting log_buffers to true by default would be less confusing.
As for 0002 patch, should the example log output with log_analyze enabled
also be updated to show the buffer information?
Sorry for reviving this old thread, but while testing the new v18 feature
- buffers being shown by default - I had the same thought about
auto_explain.log_buffers, so I wanted to chime in.
Regards,
--
Fujii Masao
NTT DATA Japan Corporation