Hi, On Thu, Feb 24, 2022 at 09:18:26PM -0800, Andres Freund wrote: > > On 2022-02-25 13:01:26 +0800, Julien Rouhaud wrote: > > On Thu, Feb 24, 2022 at 08:44:08PM +0000, Jacob Champion wrote: > > > > > > Yeah... I was following a similar track with the initial work last > > > year, but I dropped it when the cost of implementation started to grow > > > considerably. At the time, though, it looked like some overhauls to the > > > stats framework were being pursued? I should read up on that thread. > > > > Do you mean the shared memory stats patchset? IIUC this is unrelated, as > > the > > beentry stuff Michael was talking about is a different infrastructure > > (backend_status.[ch]), and I don't think there are any plans to move that to > > dynamic shared memory. > > Until a year ago the backend_status.c stuff was in in pgstat.c - I just split > them out because of the shared memory status work - so it'd not be surprising > for them to mentally be thrown in one bucket.
Right. > Basically the type of stats we're trying to move to dynamic shared memory is > about counters that should persist for a while and are accumulated across > connections etc. Whereas backend_status.c is more about tracking the current > state (what query is a backend running, what user, etc). But would it be acceptable to use dynamic shared memory in backend_status and e.g. have a dsa_pointer rather than a fixed length array? That seems like a bad idea for query text in general, but for authn_id for instance it seems less likely to hold gigantic strings, and also have more or less consistent size when provided.
