Date: Mon, 5 Aug 2019 10:30:29 -0700 (MST)
From: legrand legrand <legrand_legrand@hotmail.com>
To: pgsql-hackers@postgresql.org
Message-ID: <1565026229657-0.post@n3.nabble.com>
In-Reply-To: <20190805.162824.123166397.horikyota.ntt@gmail.com>
References: 
 <CAOBaU_YEgEiTuQr8O32TqxdoA+mM=owXKe2P1eKM_5XssR1_FQ@mail.gmail.com>
 <20190731215909.xsygisccnirdld3f@alap3.anarazel.de>
 <CAOBaU_bYGuoN8d3WXQ5HufXfkxuL3M=YCWHa33rRRR-fqLFefA@mail.gmail.com>
 <CA+TgmoYyFN3FuiC+E0Ug4ceXmfUYKpmqx6xZdLZq-F9ZJoZutg@mail.gmail.com>
 <20190801183632.7byx3knosxas4ih3@alap3.anarazel.de>
 <CAOBaU_bY3Fx+L_HL4x9pK1+9z8rDt49q=twcvrNi-fxpBdnJgg@mail.gmail.com>
 <20190801210514.qdiam2oazua6otkk@alap3.anarazel.de>
 <CAOBaU_aPixr3sj8Ov7o4eToOdA0f68ZV+Z4drn2LHn4QJTj8Tg@mail.gmail.com>
 <1564902241482-0.post@n3.nabble.com>
 <20190805.162824.123166397.horikyota.ntt@gmail.com>
Subject: Re: Feature improvement: can we add queryId for
 pg_catalog.pg_stat_activity view?
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

Kyotaro Horiguchi-4 wrote
> At Sun, 4 Aug 2019 00:04:01 -0700 (MST), legrand legrand &lt;

> legrand_legrand@

> &gt; wrote in <

> 1564902241482-0.post@.nabble

>>
>> >  However having the nested queryid in=20
>> > pg_stat_activity would be convenient to track
>> > what is a long stored functions currently doing.
>>=20
>> +1
>>=20
>> And  this could permit to get wait event sampling per queryid when
>> pg_stat_statements.track =3D all
>=20
> I'm strongly on this side emotionally, but also I'm on Tom and
> Andres's side that exposing querid that way is not the right
> thing.
>=20
> Doing that means we don't need exact correspondence between
> top-level query and queryId (in nested or multistatement queries)
> in this patch.  pg_stat_statements will allow us to do the same
> thing by having additional uint64[MaxBackends] array in
> pgssSharedState, instead of expanding PgBackendStatus array in
> core by the same size.
>=20
> regards.
>=20
> --=20
> Kyotaro Horiguchi
> NTT Open Source Software Center

Hi Kyotaro,
Thank you for this answer.
What you propose here is already available=20
Inside pg_stat_sql_plans extension (a derivative from=20
Pg_stat_statements and pg_store_plans)
And I=E2=80=99m used to this queryid behavior with top Level
Queries...
My emotion was high but I will accept it !
Regards
PAscal


--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.h=
tml