On Thu, May 11, 2017 at 1:40 AM, Remi Colinet <remi.coli...@gmail.com> wrote: > This is version 2 of the new command name PROGRESS which I wrote in order to > monitor long running SQL queries in a Postgres backend process.
It would be a good idea to add this patch to the next commit fest if you are expecting some feedback: https://commitfest.postgresql.org/14/ But please don't expect immediate feedback, the primary focus these days is to stabilize the upcoming release. > New command justification > ==================== > > [root@rco pg]# git diff --stat master.. > [...] > 58 files changed, 5972 insertions(+), 2619 deletions(-) For your first patch, you may want something less... Challenging. Please note as well that it would be nice if you review other patches to get more familiar with the community process, it is expected that for each patch submitted, an equivalent amount of review is done. That's hard to measure but for a patch as large as that you will need to pick up at least one patch equivalent in difficulty. Regarding the patch, this is way to close to the progress facility already in place. So why don't you extend it for the executor? We can likely come up with something that can help, though I see the part where the plan run by a backend is shared among all processes as a major bottleneck in performance. You have at least three concepts different here: - Store plans run in shared memory to allow access to any other processes. - Allow a process to look at the plan run by another one with a SQL interface. - Track the progress of a running plan, via pg_stat_activity. All in all, I think that a new command is not adapted, and that you had better split each concept before implementing something over-engineered like the patch attached. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers