Here is a new version that fixes the aforementioned problems.
If this patch is accepted in this form, the counters could be used for
the patch in pg_stat_database. [1]
[1]
https://www.postgresql.org/message-id/flat/783bc7f7-659a-42fa-99dd-ee0565644...@dalibo.com
--
Benoit Lobréau
Consultant
h
I found out in [1] that I am not correctly tracking the workers for
vacuum commands. I trap workers used by
parallel_vacuum_cleanup_all_indexes but not
parallel_vacuum_bulkdel_all_indexes.
Back to the drawing board.
[1]
https://www.postgresql.org/message-id/flat/783bc7f7-659a-42fa-99dd-ee056
Hi,
Here is a new version of the patch. Sorry for the long delay, I was hit
by a motivation drought and was quite busy otherwise.
The guc is now called `log_parallel_workers` and has three possible values:
* "none": disables logging
* "all": logs parallel worker info for all parallel queries
On 4/8/24 10:05, Andrey M. Borodin wrote:
Hi Benoit!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Hi thanks for the reminder,
The past month as been hectic for me.
It should calm down by next week at wich
> On 29 Feb 2024, at 11:24, Benoit Lobréau wrote:
>
> Yes, thanks for the proposal, I'll work on it on report here.
Hi Benoit!
This is kind reminder that this thread is waiting for your response.
CF entry [0] is in "Waiting on Author", I'll move it to July CF.
Thanks!
Best regards, Andrey
On 2/27/24 15:09, Tomas Vondra wrote> That is certainly true, but it's
not a new thing, I believe. IIRC we may
> not report statistics until the end of the transaction, so no progress
> updates, I'm not sure what happens if the doesn't end correctly (e.g.
> backend dies, ...). Similarly for the t
On 2024-02-27 Tu 05:03, Benoit Lobréau wrote:
On 2/25/24 23:32, Peter Smith wrote:
Also, I don't understand how the word "draught" (aka "draft") makes
sense here -- I assume the intended word was "drought" (???).
yes, that was the intent, sorry about that. English is not my native
langage
On 2/27/24 10:55, Benoit Lobréau wrote:
> 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
>> "a
On 2/25/24 23:32, Peter Smith wrote:
Also, I don't understand how the word "draught" (aka "draft") makes
sense here -- I assume the intended word was "drought" (???).
yes, that was the intent, sorry about that. English is not my native
langage and I was convinced the spelling was correct.
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 sam
On Mon, Feb 26, 2024 at 6:13 AM Tomas Vondra
wrote:
>
> 1) name of the GUC
>
> I find the "log_parallel_worker_draught" to be rather unclear :-( Maybe
> it's just me and everyone else just immediately understands what this
> does / what will happen after it's set to "on", but I find it rather
> n
Hi,
I see the thread went a bit quiet, but I think it'd be very useful (and
desirable) to have this information in log. So let me share my thoughts
about the patch / how it should work.
The patch is pretty straightforward, I don't have any comments about the
code as is. Obviously, some of the fol
> I believe both cumulative statistics and logs are needed. Logs excel in
> pinpointing specific queries at precise times, while statistics provide
> a broader overview of the situation. Additionally, I often encounter
> situations where clients lack pg_stat_statements and can't restart their
>
On 10/11/23 17:26, Imseih (AWS), Sami wrote:
Thank you for resurrecting this thread.
Well, if you read Benoit's earlier proposal at [1] you'll see that he
does propose to have some cumulative stats; this LOG line he proposes
here is not a substitute for stats, but rather a complement. I don't
>> Currently explain ( analyze ) will give you the "Workers Planned"
>> and "Workers launched". Logging this via auto_explain is possible, so I am
>> not sure we need additional GUCs or debug levels for this info.
>>
>> -> Gather (cost=10430.00..10430.01 rows=2 width=8) (actual tim
>> e=131.826..13
On 2023-Oct-09, Imseih (AWS), Sami wrote:
> > I think we should definitely be afraid of that. I am in favor of a
> > separate GUC.
I agree.
> Currently explain ( analyze ) will give you the "Workers Planned"
> and "Workers launched". Logging this via auto_explain is possible, so I am
> not sure
Hi,
This thread has been quiet for a while, but I'd like to share some
thoughts.
+1 to the idea of improving visibility into parallel worker saturation.
But overall, we should improve parallel processing visibility, so DBAs can
detect trends in parallel usage ( is the workload doing more parallel
On Tue, May 2, 2023 at 6:57 AM Amit Kapila wrote:
> We can output this at the LOG level to avoid running the server at
> DEBUG1 level. There are a few other cases where we are not able to
> spawn the worker or process and those are logged at the LOG level. For
> example, "could not fork autovacuum
On Mon, May 1, 2023 at 10:03 PM Robert Haas wrote:
>
> On Sat, Apr 22, 2023 at 7:06 AM Amit Kapila wrote:
> > I don't think introducing a GUC for this is a good idea. We can
> > directly output this message in the server log either at LOG or DEBUG1
> > level.
>
> Why not? It seems like something
On 5/1/23 18:33, Robert Haas wrote:
> Why not? It seems like something some people might want to log and
> others not. Running the whole server at DEBUG1 to get this information
> doesn't seem like a suitable answer.
Since the statement is also logged, it could spam the log with huge
queries, wh
On Sat, Apr 22, 2023 at 7:06 AM Amit Kapila wrote:
> I don't think introducing a GUC for this is a good idea. We can
> directly output this message in the server log either at LOG or DEBUG1
> level.
Why not? It seems like something some people might want to log and
others not. Running the whole s
On 4/22/23 13:06, Amit Kapila wrote:
I don't think introducing a GUC for this is a good idea. We can
directly output this message in the server log either at LOG or DEBUG1
level.
Hi,
Sorry for the delayed answer, I was away from my computer for a few
days. I don't mind removing the guc, but I
On Fri, Apr 21, 2023 at 6:34 PM Benoit Lobréau
wrote:
>
> Following my previous mail about adding stats on parallelism[1], this
> patch introduces the log_parallel_worker_draught parameter, which
> controls whether a log message is produced when a backend attempts to
> spawn a parallel worker but
Hi hackers,
Following my previous mail about adding stats on parallelism[1], this
patch introduces the log_parallel_worker_draught parameter, which
controls whether a log message is produced when a backend attempts to
spawn a parallel worker but fails due to insufficient worker slots. The
sho
24 matches
Mail list logo
