Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch) - Mailing list pgsql-hackers

From Amit Kapila
Subject Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)
Date
Msg-id CAA4eK1LoF9THdEP2np-CHosaDCF2YhCKQ+gMrsHvjGy31ypkWw@mail.gmail.com
Whole thread Raw
In response to Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)  (Masahiko Sawada <masahiko.sawada@2ndquadrant.com>)
Responses Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Mon, Apr 6, 2020 at 12:55 PM Masahiko Sawada
<masahiko.sawada@2ndquadrant.com> wrote:
>
> On Mon, 6 Apr 2020 at 16:16, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Mon, Apr 6, 2020 at 11:19 AM Masahiko Sawada
> > <masahiko.sawada@2ndquadrant.com> wrote:
> > >
> > > The attached patch changes to the above comment and removed the code
> > > that is used to un-support only buffer usage accumulation.
> > >
> >
> > So, IIUC, the purpose of this patch will be to count the buffer usage
> > due to the heap scan (in heapam_index_build_range_scan) we perform
> > while parallel create index? Because the index creation itself won't
> > use buffer manager.
>
> Oops, I'd missed Peter's comment. Btree index doesn't use
> heapam_index_build_range_scan so it's not necessary.
>

AFAIU, it uses heapam_index_build_range_scan but for writing to index,
it doesn't use buffer manager.  So, I guess probably we can accumulate
BufferUsage stats for parallel create index.  What I wanted to know is
whether the extra lookup for pg_amproc or any other catalog access via
parallel workers is fine or we somehow want to eliminate that?

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



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: WAL usage calculation patch
Next
From: Julien Rouhaud
Date:
Subject: Re: WAL usage calculation patch