Re: shared-memory based stats collector

Поиск
Список
Период
Сортировка
От Tomas Vondra
Тема Re: shared-memory based stats collector
Дата
Msg-id 2e77189a-48f0-ea50-c0b7-507d22d37032@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: shared-memory based stats collector  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Ответы Re: shared-memory based stats collector  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On 11/27/18 9:59 AM, Kyotaro HORIGUCHI wrote:
> ...
> 
> v10-0001-sequential-scan-for-dshash.patch
> v10-0002-Add-conditional-lock-feature-to-dshash.patch
>   fixed.
> v10-0003-Make-archiver-process-an-auxiliary-process.patch
>   fixed.
> v10-0004-Shared-memory-based-stats-collector.patch
>   updated not to touch guc.
> v10-0005-Remove-the-GUC-stats_temp_directory.patch
>   collected all guc-related changes.
>   updated not to break other programs.
> v10-0006-Split-out-backend-status-monitor-part-from-pgstat.patch
>   basebackup.c requires both bestats.h and pgstat.h
> v10-0007-Documentation-update.patch
>   small change related to 0005.
> 

I need to do a more thorough review of part 0006, but these patches
seems quite fine to me. I'd however merge 0007 into the other relevant
parts (it seems like a mix of docs changes for 0004, 0005 and 0006).

Thinking about it a bit more, I'm wondering if we need to keep 0004 and
0005 separate. My understanding is that the stats_temp_directory is used
only from the stats collector, so it probably does not make much sense
to keep it after 0004. We may also keep it separate and then commit both
0004 and 0005 together, of course. What do you think.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Python versions (was Re: RHEL 8.0 build)
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: libpq debug log