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

2017-05-20 Thread Amit Kapila
On Wed, May 17, 2017 at 9:43 PM, Remi Colinet wrote: > > 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

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

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

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

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

2017-05-16 Thread Magnus Hagander
On Tue, May 16, 2017 at 7:26 PM, Robert Haas wrote: > On Tue, May 16, 2017 at 2:17 AM, Michael Paquier > wrote: > > Perhaps DSM? It is not user-friendly to fail sporadically... > > Yeah. I've been thinking we might want to give each backend a >

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

2017-05-16 Thread Robert Haas
On Tue, May 16, 2017 at 2:17 AM, Michael Paquier wrote: > Perhaps DSM? It is not user-friendly to fail sporadically... Yeah. I've been thinking we might want to give each backend a backend-lifetime DSA that is created on first use. That could be useful for some

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

2017-05-16 Thread 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-13 Thread 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 child > progression directly in order to dump the whole progress

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

2017-05-12 Thread 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 progress facility advertises a

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

2017-05-11 Thread David Fetter
On Thu, May 11, 2017 at 05:24:16PM +0200, Remi Colinet wrote: > 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 wrote in > > > order

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

2017-05-11 Thread Remi Colinet
Thx for your comment. Based on other comments, I will probably convert the command into a SQL function. This allows passing arguments such as the one which can be used in the current command (VERBOSE, FORMAT). This will avoid keyword collisions. Regards Remi 2017-05-10 22:04 GMT+02:00 Pavel

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

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

2017-05-11 Thread Remi Colinet
That's good point. I will probably convert the new command to a SQL function. I was fumbling between a table or a SQL function. Oracle uses v$session_longops to track progression of long running SQL queries which have run for more than 6 seconds. But a function is much better to provide

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

2017-05-10 Thread 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 be a good idea to add this patch to the next commit fest if you

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

2017-05-10 Thread Pavel 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 lot of reserved keyword. Why? It can breaks lot

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

2017-05-10 Thread 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 wrote in > order to monitor long running SQL queries in a Postgres backend > process. Perhaps I missed something important in the discussion, but was there a good