Re: Split index and table statistics into different types of stats

On Thu, Aug 13, 2026 at 04:29:35AM +0000, Bertrand Drouvot wrote:
> So, 272 bytes for the current structure and 80 bytes for the index specific one,
> including allocation overhead. That's 192 bytes of additional allocated space
> per pending index entry.
>
> 1000 pending index entries would lead to about 188 KB per backend.
> Given that this is not a new cost, I agree that it is probably not worth reducing
> the code clarity for this.

I don't know. If more people want to argue in favor of that..

> So, index entries return the copy unchanged, worth to modify this comment on top
> of the function then?
>
> "
> * If an entry is found, copy it and increment the copy's counters with their
> "

Right, that's slightly incorrect. I'd probably just tweak it like
that:
+ * If an entry is found, copy it. For a PGSTAT_KIND_INDEX entry, just return
+ * the copy. For a PGSTAT_KIND_RELATION entry, increment the copy's counters
+ * with their subtransaction counterparts, then return the copy. The caller
+ * may need to pfree() the copy.

If you would like to word that differently, please let me know.
--
Michael