Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-08-09 Thread Remi Colinet
2017-08-01 19:57 GMT+02:00 Robert Haas : > On Tue, Aug 1, 2017 at 12:35 PM, Remi Colinet > wrote: > > I did it in version 2 of the patch. > > I'am skeptical about the use of JSON, XML, and others in such output. > > > > Does anyone use these formats (XML, JS

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-08-01 Thread Remi Colinet
l": 83334, + "blocks percent": 22, + "Filter": "(md5 ~~ '%cb%'::text)" + }

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-07-31 Thread Remi Colinet
2017-07-26 16:24 GMT+02:00 Pavel Stehule : > > > 2017-07-26 15:27 GMT+02:00 Robert Haas : > >> On Wed, Jun 21, 2017 at 10:01 AM, Remi Colinet >> wrote: >> > test=# SELECT pid, ppid, bid, concat(repeat(' ', 3 * indent),name), >> value, >>

Re: [HACKERS] [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities

2017-07-31 Thread Remi Colinet
2017-07-26 15:27 GMT+02:00 Robert Haas : > On Wed, Jun 21, 2017 at 10:01 AM, Remi Colinet > wrote: > > test=# SELECT pid, ppid, bid, concat(repeat(' ', 3 * indent),name), > value, > > unit FROM pg_progress(0,0); > > pid | ppid | bid | c

Re: [HACKERS] [PATCH] pg_reload_backend to signal SIGHUP to a specific backend

2017-06-28 Thread Remi Colinet
Hi Yugo, The patch looks fine. Installed and tested. But a similar function already exists for the Postmaster process. Datum pg_reload_conf(PG_FUNCTION_ARGS) { if (kill(PostmasterPid, SIGHUP)) { ereport(WARNING, (errmsg("failed to s

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-17 Thread Remi Colinet
2017-05-16 8:17 GMT+02:00 Michael Paquier : > On Sat, May 13, 2017 at 10:53 AM, Robert Haas > wrote: > > On Wed, May 10, 2017 at 10:05 PM, Michael Paquier > > wrote: > >> Regarding the patch, this is way to close to the progress facility > >> already in place. So why don't you extend it for the

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-17 Thread Remi Colinet
2017-05-13 14:38 GMT+02:00 Amit Kapila : > On Wed, May 10, 2017 at 10:10 PM, Remi Colinet > wrote: > > > > Parallel queries can also be monitored. The same mecanism is used to > monitor > > child workers with a slight difference: the main worker requests the > chi

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-17 Thread Remi Colinet
2017-05-13 3:53 GMT+02:00 Robert Haas : > On Wed, May 10, 2017 at 10:05 PM, Michael Paquier > wrote: > > 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? > > I don't think that's a good idea. The existing progre

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-11 Thread Remi Colinet
Stehule : > Hi > > 2017-05-10 18:40 GMT+02:00 Remi Colinet : > >> Hello, >> >> 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. >> > > This patch introduce lo

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-11 Thread Remi Colinet
2017-05-11 4:05 GMT+02:00 Michael Paquier : > On Thu, May 11, 2017 at 1:40 AM, Remi Colinet > 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

Re: [HACKERS] [PATCH v2] Progress command to monitor progression of long running SQL queries

2017-05-11 Thread Remi Colinet
ovide parameters such as the backend pid and a format specification for the output. Regards Remi 2017-05-10 21:52 GMT+02:00 David Fetter : > On Wed, May 10, 2017 at 06:40:31PM +0200, Remi Colinet wrote: > > Hello, > > > > This is version 2 of the new command name PROGRESS which I wro

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

2017-05-11 Thread Remi Colinet
both a function with parameters and a view created on the function is the solution. Regards Remi 2017-05-06 5:57 GMT+02:00 Jaime Casanova : > On 5 May 2017 at 22:38, Vinayak Pokale wrote: > > > > On Mon, Apr 17, 2017 at 9:09 PM, Remi Colinet > > wrote: > >> >

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

2017-05-11 Thread Remi Colinet
Do you have more details about the failed tests? Regards, Remi 2017-05-06 5:38 GMT+02:00 Vinayak Pokale : > > On Mon, Apr 17, 2017 at 9:09 PM, Remi Colinet > wrote: > >> Hello, >> >> I've implemented a new command named PROGRESS to monitor progression

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

2017-04-20 Thread Remi Colinet
2017-04-19 18:41 GMT+02:00 Maksim Milyutin : > On 19.04.2017 17:13, Remi Colinet wrote: > >> Maksim, >> >> >> 2017-04-18 20:31 GMT+02:00 Maksim Milyutin > <mailto:m.milyu...@postgrespro.ru>>: >> >> On 18.04.2017 17:39, Remi Colinet wrote:

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

2017-04-19 Thread Remi Colinet
27;50'::real) (2 rows) Wed 19 Apr 2017 04:44:14 PM CEST (every 1s) PLAN PROGRESS -------- Sample Scan on t_10m => rows 4031400/5793292 69% blks 75625/10 75% Sampling: system ('50'::real

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

2017-04-19 Thread Remi Colinet
Maksim, 2017-04-18 20:31 GMT+02:00 Maksim Milyutin : > On 18.04.2017 17:39, Remi Colinet wrote: > >> Hello Maksim, >> >> The core implementation I suggested for the new PROGRESS command uses >> different functions from the one used by EXPLAIN for its core >>

Re: [HACKERS] [PATCH] New command to monitor progression of long running queries

2017-04-18 Thread Remi Colinet
query. A further improvement would be to report the memory, disk and time resources used by the monitored backend. An overuse of memory, disk and time resources can prevent the SQL query to complete. Best regards Remi 2017-04-18 15:00 GMT+02:00 Maksim Milyutin : > Hi! > > > On 17.04.20