Thread: Using stat collector for collecting long SQL

Hi

> There is a often problem with taking source of long SQL strings. The
> pg_stat_activity field query is reduced to some short limit and is not too
> practical to increase this limit.

I thought it was "old story", since that track_activity_query_size can be
increased widely:
https://www.postgresql.org/message-id/flat/7b5ecc5a9991045e2f13c84e3047541d%40postgrespro.ru

[...]

> It can be base for implementation EXPLAIN PID ?
+1 for this concept, that would be very usefull for diagnosing stuck
queries.

Until now the only proposal I saw regarding this was detailled in
https://www.postgresql.org/message-id/1582756552256-0.post@n3.nabble.com
a prerequisite to be able to use extension postgrespro/pg_query_state

Regards 
PAscal



--
Sent from: https://www.postgresql-archive.org/PostgreSQL-hackers-f1928748.html

Hi,

On 2020-02-27 09:42:19 +0100, Pavel Stehule wrote:
> There is a often problem with taking source of long SQL strings. The
> pg_stat_activity field query is reduced to some short limit and is not too
> practical to increase this limit.
> 
> I have a idea to use for solution of this problem stat_collector process.
> When the query string is reduced, then full form of query string can be
> saved in stat_collector process. Maybe with execution plan. Then any
> process can read these information from this process.

How? That sounds extremely expensive.


> What do you think about this idea? It can be base for implementation
> EXPLAIN PID ?

I'm fairly strongly against adding any new dependencies on the stats
collector process. We're slowly working on getting rid of it (see the
thread about making the stats system use dynamic shared memory).

Greetings,

Andres Freund