Re: Proposal - Allow extensions to set a Plan Identifier
От | Sami Imseih |
---|---|
Тема | Re: Proposal - Allow extensions to set a Plan Identifier |
Дата | |
Msg-id | CAA5RZ0ss1=OWaWkcsB5OT=iS94NaxzURm55a_OLcrkHxy=ZQsw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal - Allow extensions to set a Plan Identifier (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Proposal - Allow extensions to set a Plan Identifier
Re: Proposal - Allow extensions to set a Plan Identifier |
Список | pgsql-hackers |
> > 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)
Вложения
В списке pgsql-hackers по дате отправления: