> * Centralization of logs: The maintenance operation can be planned in
> cron jobs. In that context, it could certainly be logged separately via
> the script. However, when I am doing an audit on a client database, I
> think it's useful to have all the relevant information in PostgreSQL logs.
Maintenance work is usually planned, so if queries
issues by the applications are not launching enough workers, it's
easy to point the blame on the maintenance activity.
> * Centralization of the configuration: If I am auditing the usage of
> parallelism, I would like to have a single GUC to enable the logging
> for all relevant information.
> * Context: Maintenance workers are part of the global pool of workers.
> To know why there is a shortage after the fact, having all the information
> on what was using workers could be useful. I tied this argument when we
> added the parallel worker info to pg_stat_database and wasn't successful.
> It would be nice to have the info somewhere.
>
> The logging for CREATE INDEX and VACUUM is in separate patches. If you
> don't mind, I would like to keep it as long as possible.
Maybe it's better to log parallel maintenance workers separately actually
if there is a truly good justification for it. As it stands now, even
pg_stat_database
does not track maintenance workers. Maybe adding logging could also be part
of that discussion?
I think logging maintenance workers will be an odd experience.
For example, if a user runs "VACUUM VERBOSE sometable",
all details are sent to the client ( including the parallel worker )
and not the logs. I doubt putting this infor alone in the log will be useful.
Also, the CREATE INDEX provides this info in DEBUG1. Although,
I think we need a separate discussion to add the # of launched workers
to then output. And maybe some documentation on how to emit
the parallel worker info for CREATE INDEX.
I wonder if we should really just have a CREATE INDEX VERBOSE syntax.
Regards,
Sami
