Hi,
On 2022-08-18 15:26:31 -0400, Greg Stark wrote:
> And indexes of course. It's a bit frustrating since without the
> catalog you won't know what table the index actually is for... But
> they're pretty important stats.
FWIW, I think we should split relation stats into table and index
stats. Historically it'd have added a lot of complexity to separate the two,
but I don't think that's the case anymore. And we waste space for index stats
by having lots of table specific fields.
> On that note though... What do you think about having the capability
> to add other stats kinds to the stats infrastructure?
Getting closer to that was one of my goals working on the shared memory stats
stuff.
> It would make a lot of sense for pg_stat_statements to add its entries here
> instead of having to reimplement a lot of the same magic.
Yes, we should move pg_stat_statements over.
It's pretty easy to get massive contention on stats entries with
pg_stat_statements, because it doesn't have support for "batching" updates to
shared stats. And reimplementing the same logic in pg_stat_statements.c
doesn't make sense.
And the set of normalized queries could probably stored in DSA as well - the
file based thing we have right now is problematic.
> To do that I guess more of the code needs to be moved to be table
> driven from the kind structs either with callbacks or with other meta
> data.
Pretty much all of it already is. The only substantial missing bit is
reading/writing of stats files, but that should be pretty easy. And of course
making the callback array extensible.
> So the kind record could contain tupledesc and the code to construct the
> returned tuple so that these functions could return any custom entry as well
> as the standard entries.
I don't see how this would work well - we don't have functions returning
variable kinds of tuples. And what would convert a struct to a tuple?
Nor do I think it's needed - if you have an extension providing a new stats
kind it can also provide accessors.
Greetings,
Andres Freund
