On 2/25/24 20:13, Tomas Vondra wrote:
> 1) name of the GUC
...
> 2) logging just the failures provides an incomplete view
> log_parallel_workers = {none | failures | all}>
> where "failures" only logs when at least one worker fails to start, and
> "all" logs everything.
>
> AFAIK Sami made the same observation/argument in his last message [1].
I like the name and different levels you propose. I was initially
thinking that the overall picture would be better summarized (an easier
to implement) with pg_stat_statements. But with the granularity you
propose, the choice is in the hands of the DBA, which is great and
provides more options when we don't have full control of the installation.
> 3) node-level or query-level?
...
> There's no value in having information about every individual temp file,
> because we don't even know which node produced it. It'd be perfectly
> sufficient to log some summary statistics (number of files, total space,
> ...), either for the query as a whole, or perhaps per node (because
> that's what matters for work_mem). So I don't think we should mimic this
> just because log_temp_files does this.
I must admit that, given my (poor) technical level, I went for the
easiest way.
If we go for the three levels you proposed, "node-level" makes even less
sense (and has great "potential" for spam).
I can see one downside to the "query-level" approach: it might be more
difficult to to give information in cases where the query doesn't end
normally. It's sometimes useful to have hints about what was going wrong
before a query was cancelled or crashed, which log_temp_files kinda does.
> I don't know how difficult would it be to track/collect this information
> for the whole query.
I am a worried this will be a little too much for me, given the time and
the knowledge gap I have (both in C and PostgreSQL internals). I'll try
to look anyway.
--
Benoit Lobréau
Consultant
http://dalibo.com
