Re: [PATCH] Increase the maximum value track_activity_query_size
От | Julien Rouhaud |
---|---|
Тема | Re: [PATCH] Increase the maximum value track_activity_query_size |
Дата | |
Msg-id | CAOBaU_ZSxVF2M=A98CPgM3dyOu=FoHChvoOB4_HdFz_rWSOtYg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PATCH] Increase the maximum value track_activity_query_size (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Список | pgsql-hackers |
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.
В списке pgsql-hackers по дате отправления: