Hello Melanie On 2021-Sep-13, Melanie Plageman wrote:
> I also think it makes sense to rename the pg_stat_buffer_actions view to > pg_stat_buffers and to name the columns using both the buffer action > type and buffer type -- e.g. shared, strategy, local. This leaves open > the possibility of counting buffer actions done on other non-shared > buffers -- like those done while building indexes or those using local > buffers. The third patch in the set does this (I wanted to see if it > made sense before fixing it up into the first patch in the set). What do you think of the idea of having the "shared/strategy/local" attribute be a column? So you'd have up to three rows per buffer action type. Users wishing to see an aggregate can just aggregate them, just like they'd do with pg_buffercache. I think that leads to an easy decision with regards to this point: > I attached a patch with the outline of this idea > (buffer_type_enum_addition.patch). It doesn't work because > pg_stat_get_buffer_actions() uses the BufferActionType as an index into > the values array returned. If I wanted to use a combination of the two > enums as an indexing mechanism (BufferActionType and BufferType), we > would end up with a tuple having every combination of the two > enums--some of which aren't valid. It might not make sense to implement > this. I do think it is useful to think of these stats as a combination > of a buffer action and a type of buffer. Does that seem sensible? (It's weird to have enum values that are there just to indicate what's the maximum value. I think that sort of thing is better done by having a "#define LAST_THING" that takes the last valid value from the enum. That would free you from having to handle the last value in switch blocks, for example. LAST_OCLASS in dependency.h is a precedent on this.) -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/ "That sort of implies that there are Emacs keystrokes which aren't obscure. I've been using it daily for 2 years now and have yet to discover any key sequence which makes any sense." (Paul Thomas)
