Hi,
Thanks for your imput ! I will fix the doc as proposed and do the split
as soon as I have time.
On 10/1/24 09:27, Michael Paquier wrote:
I'm less
a fan of the addition for utilities because these are less common
operations.
My thought process was that in order to size max_parallel_workers we
need to
have information on the maintenance parallel worker and "query" parallel
workers.
Actually, could we do better than what's proposed here? How about
presenting an aggregate of this data in pg_stat_statements for each
query instead?
I think both features are useful.
My collegues and I had a discussion about what could be done to improve
parallelism observability in PostgreSQL [0]. We thought about several
places to do it for several use cases.
Guillaume Lelarge worked on pg_stat_statements [1] and
pg_stat_user_[tables|indexes] [2]. I proposed a patch for the logs [3].
As a consultant, I frequently work on installation without
pg_stat_statements and I cannot install it on the client's production
in the timeframe of my intervention.
pg_stat_database is available everywhere and can easily be sampled by
collectors/supervision services (like check_pgactivity).
Lastly the number would be more precise/easier to make sense of, since
pg_stat_statement has a limited size.
[0]
https://www.postgresql.org/message-id/flat/d657df20-c4bf-63f6-e74c-cb85a81d0...@dalibo.com
[1]
https://www.postgresql.org/message-id/CAECtzeWtTGOK0UgKXdDGpfTVSa5bd_VbUt6K6xn8P7X%2B_dZqKw%40mail.gmail.com
[2]
https://www.postgresql.org/message-id/flat/CAECtzeXXuMkw-RVGTWvHGOJsmFdsRY%2BjK0ndQa80sw46y2uvVQ%40mail.gmail.com
[3]
https://www.postgresql.org/message-id/8123423a-f041-4f4c-a771-bfd96ab235b0%40dalibo.com
--
Benoit Lobréau
Consultant
http://dalibo.com
