From: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> |
---|---|
To: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
Cc: | Ekaterina Sokolova <e(dot)sokolova(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: RFC: Logging plan of the running query |
Date: | 2021-11-15 14:15:49 |
Message-ID: | CALj2ACWG16wSdkkPR93koq9JS84gYh93MruQaij8CX+hwydHTg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Nov 15, 2021 at 6:29 PM torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> wrote:
> > 3) I think SendProcSignalForLogInfo can be more generic, meaning, it
> > can also send signal to auxiliary processes if asked to do this will
> > simplify the things for pg_log_backend_memory_contexts and other
> > patches like pg_print_backtrace. I would imagine it to be "bool
> > SendProcSignalForLogInfo(pid_t pid, ProcSignalReason reason, bool
> > signal_aux_proc);".
>
> I agree with your idea.
> Since sending signals to auxiliary processes to dump memory contexts and
> pg_print_backtrace is still under discussion, IMHO it would be better to
> refactor SendProcSignalForLogInfo after these patches are commited.
+1.
I have another comment: isn't it a good idea that an overloaded
version of the new function pg_log_query_plan can take the available
explain command options as a text argument? I'm not sure if it is
possible to get the stats like buffers, costs etc of a running query,
if yes, something like pg_log_query_plan(pid, 'buffers',
'costs'....);? It looks to be an overkill at first sight, but these
can be useful to know more detailed plan of the query.
Thoughts?
Regards,
Bharath Rupireddy.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2021-11-15 14:32:29 | Re: Commitfest 2021-11 Patch Triage - Part 2 |
Previous Message | Bharath Rupireddy | 2021-11-15 14:02:38 | pg_waldump stucks with options --follow or -f and --stats or -z |