Re: Use pgBufferUsage for block reporting in analyze

On Wed, Jul 24, 2024 at 1:58 AM Anthonin Bonnefoy
<anthonin(dot)bonnefoy(at)datadoghq(dot)com> wrote:
>
> On Mon, Jul 22, 2024 at 10:59 PM Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> > The first line would vary depending on whether an autovacuum worker or
> > not. And the above suggestion includes a change of term "row" to
> > "tuple" for better consistency with VACUUM VERBOSE outputs. I think it
> > would be great if autoanalyze also writes logs in the same format.
> > IIUC with the patch, autoanalyze logs don't include the page and tuple
> > statistics.
>
> One issue is that the number of scanned pages, live tuples and dead
> tuples is only available in acquire_sample_rows which is where the log
> containing those stats is emitted. I've tried to implement the
> following in 0003:
> - Sampling functions now accept an AcquireSampleStats struct to store
> pages and tuples stats
> - Log is removed from sampling functions
> - do_analyze_rel now outputs scanned and tuples statistics when
> relevant. sampling from fdw doesn't provide those statistics so they
> are not displayed in those cases.

Studying how we write verbose log messages, it seems that currently
ANALYZE (autoanalyze) lets tables and FDWs write logs in its own
format. Which makes sense to me as some instruments for heap such as
dead tuple might not be necessary for FDWs and FDW might want to write
other information such as executed queries. An alternative idea would
be to pass StringInfo to AcquireSampleRowsFunc() so that callback can
write its messages there. This is somewhat similar to what we do in
the EXPLAIN command (cf, ExplainPropertyText() etc). It could be too
much but I think it could be better than writing logs in the single
format.

>
> I've also slightly modified 0002 to display "automatic analyze" when
> we're inside an autovacuum worker, similar to what's done with vacuum
> output.

+1

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com