On Mon, Dec 23, 2019 at 1:10 PM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
>
> On Sun, Dec 22, 2019 at 09:06:41AM +0100, Julien Rouhaud wrote:
> >On Sun, Dec 22, 2019 at 1:03 AM Tomas Vondra
> ><tomas.vondra@2ndquadrant.com> wrote:
> >>
> >> On Sat, Dec 21, 2019 at 04:25:05PM -0500, Tom Lane wrote:
> >> >> What is the overhead here except the memory consumption?
> >> >
> >> >The time to copy those strings out of shared storage, any time
> >> >you query pg_stat_activity.
> >> >
> >>
> >> IMO that seems like a reasonable price to pay, if you want to see
> >> complete queries and bump the track_activity_query_size value up.
> >
> >Couldn't be pg_stat_statements (or any similar extension) queryid
> >exposure in pg_stat_activity [1] also an alternative? You wouldn't
> >have the parameters but maybe the normalized query would be enough for
> >most analysis. Now, maybe pg_stat_statements jumble overhead for such
> >large statements would be even more problematic.
> >
>
> But that would effectively add dependency on pg_stat_statements, no? I
> don't think we want that.
The queryid field is part of the core, so no dependency is added. You
just get a somewhat useless NULL value returned until you load an
extension that compute a queryid, which may be pg_stat_statements but
any other one will work too.
