> > This adds a planId to pg_stat_get_activity ( not pg_stat_activity ).
> > An extension
> > can offer its own view, similar to pg_stat_activity, which can include planId.
> >
> > Note that there are no documentation updates required here as we don't
> > have per-field documentation for pg_stat_get_activity.
> >
> > These 2 patches can probably be combined , but will leave them like
> > this for now.
>
> The split makes more sense to me, and FWIW I see more value in 0001
> that provides an anchor on the backend side for extensions to plug in
> a plan ID that can be tracked across multiple layers.
Yes, I think this is a step in the right direction for this functionality.
> I am less
> convinced about the need for 0002 that adds this information to
> pg_stat_activity at this stage, as the getter routine in 0001 is
> enough to know what's happening, roughly.
I agree. I don't think exposing this in a system view is required at this
time. Once extensions start to use it, and it becomes obvious it should
be exposed in a system view, that discussion can be had at that
time.
> Hmm. Shouldn't we document all such expectations,
> which are similar to a query ID?
I had a lazy comment :)
* For the same reasons as the query identifiers (see above),
but, I went ahead and commented it similar to how we document
pgstat_report_query_id and pgstat_get_my_query_id routines.
attached is v2-0001
--
Sami Imseih
Amazon Web Services (AWS)
