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

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)
Дата
Msg-id CAH2-Wz=FYJeF=8G1exTjEJpTwqQ-KeeL4Lde3cVGJ+VE2H6p1w@mail.gmail.com
обсуждение исходный текст
Ответ на Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)
Список pgsql-hackers
On Wed, Apr 1, 2020 at 7:52 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> Peter, Is this behavior expected?
>
> Let me summarize the situation so that it would be easier for Peter to
> comment.  Julien has noticed that parallel vacuum and parallel create
> index doesn't seem to report correct values for buffer usage stats.
> Sawada-San wrote a patch to fix the problem for both the cases.  We
> expect that 'total_read_blks' as reported in pg_stat_statements should
> give the same value for parallel and non-parallel operations.  We see
> that is true for parallel vacuum and previously we have the same
> observation for the parallel query. Now, for parallel create index
> this doesn't seem to be true as test results by Dilip show that.  We
> have two possibilities here (a) there is some bug in Sawada-San's
> patch or (b) this is expected behavior for parallel create index.
> What do you think?

nbtree CREATE INDEX doesn't even go through the buffer manager. The
difference that Dilip showed is probably due to extra catalog accesses
in the two parallel workers -- pg_amproc lookups, and the like. Those
are rather small differences, overall.

Can Dilip demonstrate the the "extra" buffer accesses are
proportionate to the number of workers launched in some constant,
predictable way?

-- 
Peter Geoghegan



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: pg_stat_statements issue with parallel maintenance (Was Re: WALusage calculation patch)
Следующее
От: Etsuro Fujita
Дата:
Сообщение: Re: [HACKERS] advanced partition matching algorithm forpartition-wise join