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

From Ibrar Ahmed
Subject Re: shared-memory based stats collector
Date
Msg-id CALtqXTdyEioaush=41y=PL96oPv-PHa6G9quFMY2kUd-WZzAcw@mail.gmail.com
Whole thread Raw
In response to Re: shared-memory based stats collector  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: shared-memory based stats collector  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
List pgsql-hackers


On Wed, Apr 7, 2021 at 8:05 AM Kyotaro Horiguchi <horikyota.ntt@gmail.com> wrote:
At Tue, 6 Apr 2021 09:32:16 -0700, Andres Freund <andres@anarazel.de> wrote in
> Hi,
>
> On 2021-04-05 02:29:14 -0700, Andres Freund wrote:
..
> I'm inclined to push patches
> [PATCH v60 05/17] pgstat: split bgwriter and checkpointer messages.
> [PATCH v60 06/17] pgstat: Split out relation stats handling from AtEO[Sub]Xact_PgStat() etc.
> [PATCH v60 09/17] pgstat: xact level cleanups / consolidation.
> [PATCH v60 10/17] pgstat: Split different types of stats into separate files.
> [PATCH v60 12/17] pgstat: reorder file pgstat.c / pgstat.h contents.

FWIW..

05 is a straight forward code-rearrange and reasonable to apply.

06 is same as above and it seems to make things cleaner.

09 mainly adds ensure_tabtat_xact_level() to remove repeated code
  blocks a straight-forward way. I wonder if
  pgstat_xact_stack_level_get() might better be
  pgstat_get_xact_stack_level(), but I'm fine with the name in the
  patch.

10 I found that the kind in "pgstat_kind" meant the placeholder for
  specific types.  It looks good to separate them into smaller pieces.
  It is also a simple rearrangement of code.

> pgstat.c is very long, and it's hard to find an order that makes sense
> and is likely to be maintained over time. Splitting the different

  I deeply agree to "hard to find an order that makes sense".

12 I'm not sure how it looks after this patch (I failed to apply 09 at
  my hand.), but it is also a simple rearrangement of code blocks.

> to v14. They're just moving things around, so are fairly low risk. But
> they're going to be a pain to maintain. And I think 10 and 12 make
> pgstat.c a lot easier to understand.

I think that pgstat.c doesn't get frequent back-patching.  It seems to
me that at least 10 looks good.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center



The patch does not apply, and require rebase,
1 out of 8 hunks FAILED -- saving rejects to file src/include/pgstat.h.rej
patching file src/backend/access/transam/xlog.c
Hunk #1 succeeded at 8758 (offset 34 lines).
patching file src/backend/postmaster/checkpointer.c
Hunk #3 succeeded at 496 with fuzz 1.
Hunk #4 FAILED at 576.
1 out of 6 hunks FAILED -- saving rejects to file src/backend/postmaster/checkpointer.c.rej
patching file src/backend/postmaster/pgstat.c

I am changing the status to "Waiting on Author".

--
Ibrar Ahmed

pgsql-hackers by date:

Previous
From: Ibrar Ahmed
Date:
Subject: Re: Column Filtering in Logical Replication
Next
From: Ibrar Ahmed
Date:
Subject: Re: Improve join selectivity estimation using extended statistics