Hi! I've meant exactly the thing you mentioned -
> > > By queries you mean particular queries, not transactions? And since > > they have an assigned ID it means that the query is already executing > > and we want to enable the tracking in another session, right? > > I think that was the idea. The query identifier generated for a > specific statement is stable so we could have a GUC variable with a > list of query id and only queries matching the provided query ids > would be sampled. This would make it easier to generate traces for a > specific query within a session. > > This one. When maintaining production systems with high load rate we often encountered necessity to trace a number of queries with known IDs (that was the case for Oracle environments, but Postgres is not very different from this point of view), because enabling tracing for the whole session would immediately result in thousands of trace spans in the system with throughput like hundreds or even thousands of tps, when we need, say, to trace a single problematic query. Thank you! -- Regards, Nikita Malakhov Postgres Professional The Russian Postgres Company https://postgrespro.ru/
