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 mecanism is used to
>> > monitor
>> > child workers with a slight difference:
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
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
> child
> > progression directly in or
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
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
> backend-lifetime DSA that is created on first use.
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 parallel query stuff and maybe fo
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 executor?
>
> I don't think that's a good idea. The exis
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 tree in shared
> memory.
>
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 fixed number of counters wi
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 to monitor long run
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 Ste
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 be a good idea to add this patch
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 parameter
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 are expecting some feedbac
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 of
applications. Cannot
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
16 matches
Mail list logo