Re: WAL-logging facility for pgstats kinds

2025-02-16 Thread Michael Paquier
On Sat, Feb 15, 2025 at 10:31:33AM +0100, Cédric Villemain wrote: > Additionally, there is significant potential for external applications to > leverage the PostgreSQL stats system to collect metrics instead of relying > on relational tables, promising a highly efficient solution. In such cases, >

Re: WAL-logging facility for pgstats kinds

2025-02-15 Thread Cédric Villemain
On 12/02/2025 01:50, Michael Paquier wrote: On Mon, Feb 10, 2025 at 11:43:30AM -0500, Andres Freund wrote: Because I saw this being moved to the new CF: I continue to *strenuously* object to this design. As outlined upthread, I think it's going into the completely wrong direction. Right. F

Re: WAL-logging facility for pgstats kinds

2025-02-11 Thread Michael Paquier
On Mon, Feb 10, 2025 at 11:43:30AM -0500, Andres Freund wrote: > Because I saw this being moved to the new CF: I continue to *strenuously* > object to this design. As outlined upthread, I think it's going into the > completely wrong direction. Right. FWIW, I'm not sure that we can absolutely just

Re: WAL-logging facility for pgstats kinds

2025-02-10 Thread Andres Freund
Hi, On 2025-01-14 12:54:36 +0900, Michael Paquier wrote: > On Fri, Jan 10, 2025 at 01:46:53PM +0900, Michael Paquier wrote: > > I'd rather use RecoveryInProgress() here even if XLogInsertAllowed() > > is a synonym of that, minus the update of LocalXLogInsertAllowed for > > the local process. > >

Re: WAL-logging facility for pgstats kinds

2025-01-13 Thread Michael Paquier
On Fri, Jan 10, 2025 at 01:46:53PM +0900, Michael Paquier wrote: > I'd rather use RecoveryInProgress() here even if XLogInsertAllowed() > is a synonym of that, minus the update of LocalXLogInsertAllowed for > the local process. I've applied v2-0002 for the new header as it is useful on its own. Re

Re: WAL-logging facility for pgstats kinds

2025-01-09 Thread Michael Paquier
On Tue, Dec 31, 2024 at 11:29:26AM +, Bertrand Drouvot wrote: > === 1 > > + * Copyright (c) 2001-2024, PostgreSQL Global Development Group > > As pgstat_kind.h is a new file, s/Copyright (c) 2001-2024/Copyright (c) 2025/ > maybe? Fixed. > No more comments, as v2-0002 is "just" moving so

Re: WAL-logging facility for pgstats kinds

2025-01-08 Thread Michael Paquier
On Thu, Jan 02, 2025 at 08:08:42PM -0500, Andres Freund wrote: > I can't think of a real case where we would want to WAL log the stats > themselves, rather than re-emitting stats during replay based on the WAL > record of the "underlying object". > > Do you have counter-examples? I'm not sure if

Re: WAL-logging facility for pgstats kinds

2025-01-02 Thread Andres Freund
Hi, On 2024-12-27 12:32:25 +0900, Michael Paquier wrote: > While brainstorming on the contents of the thread I have posted a > couple of days ago, I have been looking at what could be done so as > pgstats and WAL-logging could work together. This was point 2) from > this message: > https://www.po

Re: WAL-logging facility for pgstats kinds

2024-12-31 Thread Bertrand Drouvot
Hi, On Tue, Dec 31, 2024 at 09:52:31AM +0900, Michael Paquier wrote: > On Fri, Dec 27, 2024 at 12:32:25PM +0900, Michael Paquier wrote: > > For clarity, the patch set has been split into several pieces, I hope > > rather edible: > > - 0001, a fix I've posted on a different thread [1], used in patc

Re: WAL-logging facility for pgstats kinds

2024-12-30 Thread Michael Paquier
On Fri, Dec 27, 2024 at 12:32:25PM +0900, Michael Paquier wrote: > For clarity, the patch set has been split into several pieces, I hope > rather edible: > - 0001, a fix I've posted on a different thread [1], used in patch > 0004 to test this new facility. > - 0002, a refactoring piece to be able t