Re: shared-memory based stats collector - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: shared-memory based stats collector
Date
Msg-id 2e77189a-48f0-ea50-c0b7-507d22d37032@2ndquadrant.com
Whole thread Raw
In response to Re: shared-memory based stats collector  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: shared-memory based stats collector  (Alvaro Herrera <alvherre@2ndquadrant.com>)
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: Python versions (was Re: RHEL 8.0 build)
Next
From: Peter Eisentraut
Date:
Subject: Re: libpq debug log