Re: Feature improvement: can we add queryId for pg_catalog.pg_stat_activity view?

On 2021-Mar-31, Bruce Momjian wrote:

> On Wed, Mar 31, 2021 at 11:25:32AM +0800, Julien Rouhaud wrote:
> > On Thu, Mar 25, 2021 at 10:36:38AM +0800, Julien Rouhaud wrote:
> > > On Wed, Mar 24, 2021 at 01:02:00PM -0300, Alvaro Herrera wrote:

> > > > I find it odd that there's executor code that acquires the current query
> > > > ID from pgstat, after having been put there by planner or ExecutorStart
> > > > itself. Seems like a modularity violation. I wonder if it would make
> > > > more sense to have the value maybe in struct EState (or perhaps there's
> > > > a better place -- but I don't think they have a way to reach the
> > > > QueryDesc anyhow), put there by ExecutorStart, so that places such as
> > > > execParallel, nodeGather etc don't have to fetch it from pgstat but from
> > > > EState.
> > >
> > > The current queryid is already available in the Estate, as the underlying
> > > PlannedStmt contains it. The problem is that we want to display the top level
> > > queryid, not the current query one, and the top level queryid is held in
> > > pgstat.
> >
> > So is the current approach ok? If not I'm afraid that detecting and caching
> > the top level queryid in the executor parts would lead to some code
> > duplication.
>
> I assume it is since Alvaro didn't reply. I am planning to apply this
> soon.

I'm afraid I don't know enough about how parallel query works to make a
good assessment on this being a good approach or not -- and no time at
present to figure it all out.

--
Álvaro Herrera 39°49'30"S 73°17'W
"I think my standards have lowered enough that now I think 'good design'
is when the page doesn't irritate the living f*ck out of me." (JWZ)