Re: Use pgstat_kind_infos to read fixed shared stats structs

2024-07-01 Thread Michael Paquier
On Mon, Jul 01, 2024 at 02:48:19PM +0900, Michael Paquier wrote: > So, how about trying to remove the dependency to the fixed shared > stats structures in PgStat_ShmemControl and PgStat_Snapshot? I'd like > to think that these should be replaced with an area allocated in > shared memory and TopMem

Re: Use pgstat_kind_infos to read fixed shared stats structs

2024-06-30 Thread Michael Paquier
On Wed, May 08, 2024 at 10:21:56AM +0900, Michael Paquier wrote: > Yup, I've looked at that yesterday and the read order remains the same > so I don't see a need for a version bump. While looking at this stuff again, I got no objections for it except a few edits to make the new code more consisten

Re: Use pgstat_kind_infos to read fixed shared stats structs

2024-05-07 Thread Michael Paquier
On Tue, May 07, 2024 at 02:07:42PM -0500, Tristan Partin wrote: > On Tue May 7, 2024 at 1:29 PM CDT, Andres Freund wrote: >> I think it's a good idea. I'd really like to allow extensions to register new >> types of stats eventually. Stuff like pg_stat_statements having its own, >> fairly ... medioc

Re: Use pgstat_kind_infos to read fixed shared stats structs

2024-05-07 Thread Tristan Partin
On Tue May 7, 2024 at 1:29 PM CDT, Andres Freund wrote: Hi, On 2024-05-06 14:07:53 -0500, Tristan Partin wrote: > Instead of needing to be explicit, we can just iterate the > pgstat_kind_infos array to find the memory locations to read into. > This was originally thought of by Andres in > 5891c

Re: Use pgstat_kind_infos to read fixed shared stats structs

2024-05-07 Thread Andres Freund
Hi, On 2024-05-06 14:07:53 -0500, Tristan Partin wrote: > Instead of needing to be explicit, we can just iterate the > pgstat_kind_infos array to find the memory locations to read into. > This was originally thought of by Andres in > 5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd. > > Not a fix, per s

Re: Use pgstat_kind_infos to read fixed shared stats structs

2024-05-07 Thread Tristan Partin
On Tue May 7, 2024 at 1:01 AM CDT, Michael Paquier wrote: On Tue, May 07, 2024 at 12:44:51AM -0500, Tristan Partin wrote: > Thanks for the feedback Michael. Should I just throw the patch in the next > commitfest so it doesn't get left behind? Better to do so, yes. I have noted this thread in my

Re: Use pgstat_kind_infos to read fixed shared stats structs

2024-05-06 Thread Michael Paquier
On Tue, May 07, 2024 at 12:44:51AM -0500, Tristan Partin wrote: > Thanks for the feedback Michael. Should I just throw the patch in the next > commitfest so it doesn't get left behind? Better to do so, yes. I have noted this thread in my TODO list, but we're a couple of weeks away from the next C

Re: Use pgstat_kind_infos to read fixed shared stats structs

2024-05-06 Thread Tristan Partin
On Mon May 6, 2024 at 9:50 PM CDT, Michael Paquier wrote: On Mon, May 06, 2024 at 02:07:53PM -0500, Tristan Partin wrote: > This was originally thought of by Andres in > 5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd. +1 because you are removing a duplication between the order of the items in PgStat_K

Re: Use pgstat_kind_infos to read fixed shared stats structs

2024-05-06 Thread Michael Paquier
On Mon, May 06, 2024 at 02:07:53PM -0500, Tristan Partin wrote: > This was originally thought of by Andres in > 5891c7a8ed8f2d3d577e7eea34dacff12d7b6bbd. +1 because you are removing a duplication between the order of the items in PgStat_Kind and the order when these are read. I suspect that nobod