Re: BUG #16109: Postgres planning time is high across version (Exposebuffer usage during planning in EXPLAIN) - Mailing list pgsql-hackers

From Julien Rouhaud
Subject Re: BUG #16109: Postgres planning time is high across version (Exposebuffer usage during planning in EXPLAIN)
Date
Msg-id CAOBaU_YAN6PW4perkROgXWtRmDNX8tvKwjgDpsR6wYetEUahGQ@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16109: Postgres planning time is high across version (Exposebuffer usage during planning in EXPLAIN)  (Julien Rouhaud <rjuju123@gmail.com>)
Responses Re: BUG #16109: Postgres planning time is high across version(Expose buffer usage during planning in EXPLAIN)  (Justin Pryzby <pryzby@telsasoft.com>)
List pgsql-hackers
On Fri, Jan 24, 2020 at 10:06 PM Julien Rouhaud <rjuju123@gmail.com> wrote:
>
> On Fri, Jan 24, 2020 at 6:55 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
> >
> > On Wed, Nov 13, 2019 at 11:39:04AM +0100, Julien Rouhaud wrote:
> > > (moved to -hackers)
> > >
> > > On Tue, Nov 12, 2019 at 9:55 PM Andres Freund <andres@anarazel.de> wrote:
> > > >
> > > > This last point is more oriented towards other PG developers: I wonder
> > > > if we ought to display buffer statistics for plan time, for EXPLAIN
> > > > (BUFFERS). That'd surely make it easier to discern cases where we
> > > > e.g. access the index and scan a lot of the index from cases where we
> > > > hit some CPU time issue. We should easily be able to get that data, I
> > > > think, we already maintain it, we'd just need to compute the diff
> > > > between pgBufferUsage before / after planning.
> > >
> > > That would be quite interesting to have.  I attach as a reference a
> > > quick POC patch to implement it:
> >
> > +1
> >
> > +       result.shared_blks_hit = stop->shared_blks_hit - start->shared_blks_hit;
> > +       result.shared_blks_read = stop->shared_blks_read - start->shared_blks_read;
> > +       result.shared_blks_dirtied = stop->shared_blks_dirtied -
> > +               start->shared_blks_dirtied;
> > [...]
> >
> > I think it would be more readable and maintainable using a macro:
> >
> > #define CALC_BUFF_DIFF(x) result.##x = stop->##x - start->##x
> > CALC_BUFF_DIFF(shared_blks_hit);
> > CALC_BUFF_DIFF(shared_blks_read);
> > CALC_BUFF_DIFF(shared_blks_dirtied);
> > ...
> > #undefine CALC_BUFF_DIFF
>
> Good idea.  Note that you can't use preprocessor concatenation to
> generate something else than a token or a number, so the ## can just
> be removed here.

Rebase due to conflict with 3ec20c7091e97.

Attachment

pgsql-hackers by date:

Previous
From: Kasahara Tatsuhito
Date:
Subject: Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)
Next
From: Michael Paquier
Date:
Subject: Re: Autovacuum on partitioned table