Horton

Re: pg_stat_statements issue with parallel maintenance (Was Re: WAL usage calculation patch)

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Masahiko Sawada <masahiko.sawada@2ndquadrant.com>
Cc: Peter Geoghegan <pg@bowt.ie>, Julien Rouhaud <rjuju123@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Robert Haas <robertmhaas@gmail.com>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2020-04-08T09:05:44Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Change the display of WAL usage statistics in Explain.

  2. Cosmetic fixups for WAL usage work.

  3. Allow parallel create index to accumulate buffer usage stats.

  4. Allow autovacuum to log WAL usage statistics.

  5. Add the option to report WAL usage in EXPLAIN and auto_explain.

  6. Allow pg_stat_statements to track WAL usage statistics.

  7. Add infrastructure to track WAL usage.

  8. Include information on buffer usage during planning phase, in EXPLAIN output, take two.

  9. Include information on buffer usage during planning phase, in EXPLAIN output.

  10. Allow parallel vacuum to accumulate buffer usage.

  11. Allow pg_stat_statements to track planning statistics.

On Wed, Apr 8, 2020 at 1:49 PM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Wed, 8 Apr 2020 at 16:04, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Wed, Apr 8, 2020 at 11:53 AM Masahiko Sawada
> > <masahiko.sawada@2ndquadrant.com> wrote:
> > >
> > > On Wed, 8 Apr 2020 at 14:44, Amit Kapila <amit.kapila16@gmail.com> wrote:
> > > >
> > > >
> > > > Thanks for the investigation.  I don't see we can do anything special
> > > > about this.  In an ideal world, this should be done once and not for
> > > > each worker but I guess it doesn't matter too much.  I am not sure if
> > > > it is worth adding a comment for this, what do you think?
> > > >
> > >
> > > I agree with you. If the differences were considerably large probably
> > > we would do something but I think we don't need to anything at this
> > > time.
> > >
> >
> > Fair enough, can you once check this in back-branches as this needs to
> > be backpatched?  I will do that once by myself as well.
>
> I've done the same test with HEAD of both REL_12_STABLE and
> REL_11_STABLE. I think the patch needs to be backpatched to PG11 where
> parallel index creation was introduced. I've attached the patches
> for PG12 and PG11 I used for this test for reference.
>

Thanks, I will once again verify and push this tomorrow if there are
no other comments.

-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com