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

[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, JSON, YAML) for EXPLAIN output?
> > I suspect only TEXT format is being used.
>
> Do you have any reason to suspect that others aren't being used?  The
> default format for anything is likely to be the most commonly-used
> one, but I don't think that proves the others are unused.
>
> Even if it were true, it wouldn't be a good justification for
> inventing an entirely new machine-readable format, at least not IMHO.
>

In version 3, my idea was to use a similar output as the one used for
Ora..e database with the v$session_longops dynamic table.
May be this is not such a good idea then. Though, it seems very handy at
1st sight.

I can revert to TEXT, JSON, XML and YAML. I will need to modify EXPLAIN
code in order to share some common parts for output formatting. Basically,
this would not change the code of EXPLAIN unless than moving some functions
in a pg_report.c file and with function names starting by ReportXXX instead
of ExplainXXX . Duplicating code for such output is not an option.

Rgds


>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

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

[Adrien Nayrat]

On 08/01/2017 06:35 PM, Remi Colinet wrote:
> Does anyone use these formats (XML, JSON, YAML) for EXPLAIN output?

Yes : http://tatiyants.com/pev/#/plans :)


-- 
Adrien NAYRAT

http://dalibo.com - http://dalibo.org



signature.asc
Description: OpenPGP digital signature

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

[Pavel Stehule]

2017-08-01 18:35 GMT+02:00 Remi Colinet :

> I did it in version 2 of the patch.
> The patch could yield TEXT, JSON, and XML ouput.
>
> For below query, it gives:
>
> => Terminal 1
> test=# select * from t_10m, t_1m where t_10m.md5 like '%cb%';
>
> => Terminal 2
> test=# \watch PROGRESS 9546;
>Wed 10 May 2017 06:29:59 PM CEST (every 1s)
>
>   PLAN
> PROGRESS
> 
> -
>  status: 
>  query: select * from t_10m, t_1m where t_10m.md5 like '%cb%';
>  time used (s): 10
>  Nested Loop
>->  Seq Scan on t_1m => rows 7/100 0% => blks 8334/8334 100%
>->  Materialize => file read readptrcount=1 rows write=1189285
> read=6584854 disk use (bytes) 53842965
>  ->  Seq Scan on t_10m => rows 1145596/738172 155%
>Filter: (md5 ~~ '%cb%'::text)
>  total disk space used (MB) 51
> (9 rows)
>
> => Terminal 2
> test=# PROGRESS (FORMAT JSON) 9546;
> PLAN PROGRESS
> --
>  [   +
>"status": "",  +
>"query": "select * from t_10m, t_1m where t_10m.md5 like '%cb%';",+
>"time used (s)": 0,   +
>"single worker": {+
>  "Node Type": "Nested Loop", +
>  "Partial Mode": "", +
>  "Operation": "single worker",   +
>  "Parent Relationship": "single worker", +
>  "Custom Plan Provider": "(@\u0004\u0001",   +
>  "Parallel Aware": false,+
>  "Outer": {  +
>"Node Type": "Seq Scan",  +
>"Strategy": "",   +
>"Partial Mode": "single worker",  +
>"Operation": "Outer", +
>"Parent Relationship": "Outer",   +
>"Custom Plan Provider": "(@\u0004\u0001", +
>"Parallel Aware": false,  +
>"relation": "t_1m",   +
>"rows fetched": 1,+
>"rows total": 100,+
>"rows percent": 0,+
>"blocks fetched": 8334,   +
>"blocks total": 8334, +
>"blocks percent": 100 +
>  },  +
>  "Inner": {  +
>"Node Type": "Materialize",   +
>"Strategy": "",   +
>"Partial Mode": "single worker",  +
>"Operation": "Inner", +
>"Parent Relationship": "Inner",   +
>"Custom Plan Provider": "(@\u0004\u0001", +
>"Parallel Aware": false,  +
>"file store": "write",+
>"readptrcount": 1,+
>"rows write": 297256, +
>"rows read": 0,   +
>"disk use (bytes)": 11911168, +
>"Outer": {+
>  "Node Type": "Seq Scan",+
>  "Strategy": "", +
>  "Partial Mode": "Inner",+
>  "Operation": "Outer",   +
>  "Parent Relationship": "Outer", +
>  "Custom Plan Provider": "HtFH\b[]\u000f\u001f", +
>  "Parallel Aware": false,+
>  "relation": "t_10m",+
>  "rows fetched": 253566, +
>  "rows total": 738172,   +
>  "rows percent": 34, +
>  "blocks fetched": 

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

[Michael Paquier]

On Tue, Aug 1, 2017 at 7:17 PM, Andres Freund  wrote:
> On 2017-08-01 19:11:55 +0200, Michael Paquier wrote:
>> I think that Depesz makes use of a non-default format for its
>> explain.depesz.com, or he would have a hard time maintaining a
>> deparsing API for its application.
>
> Hm? e.d.c accepts the text explain format, so I'm unclear on what you're
> saying here.

Ah, right. I thought it did...
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[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, JSON, YAML) for EXPLAIN output?
> I suspect only TEXT format is being used.

Do you have any reason to suspect that others aren't being used?  The
default format for anything is likely to be the most commonly-used
one, but I don't think that proves the others are unused.

Even if it were true, it wouldn't be a good justification for
inventing an entirely new machine-readable format, at least not IMHO.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Andres Freund]

On 2017-08-01 19:11:55 +0200, Michael Paquier wrote:
> I think that Depesz makes use of a non-default format for its
> explain.depesz.com, or he would have a hard time maintaining a
> deparsing API for its application.

Hm? e.d.c accepts the text explain format, so I'm unclear on what you're
saying here.

Andres


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Michael Paquier]

On Tue, Aug 1, 2017 at 6:35 PM, Remi Colinet  wrote:
> I'am skeptical about the use of JSON, XML, and others in such output.

You should not.

> Does anyone use these formats (XML, JSON, YAML) for EXPLAIN output?
> I suspect only TEXT format is being used.

I think that Depesz makes use of a non-default format for its
explain.depesz.com, or he would have a hard time maintaining a
deparsing API for its application. JSON is for example easy to extract
and reformat when doing analysis of the inner planner nodes, and
Postgres has json and xml data types, which makes analysis with SQL
even easier sometimes.
-- 
Michael


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Remi Colinet]

I did it in version 2 of the patch.
The patch could yield TEXT, JSON, and XML ouput.

For below query, it gives:

=> Terminal 1
test=# select * from t_10m, t_1m where t_10m.md5 like '%cb%';

=> Terminal 2
test=# \watch PROGRESS 9546;
   Wed 10 May 2017 06:29:59 PM CEST (every 1s)

  PLAN
PROGRESS
-
 status: 
 query: select * from t_10m, t_1m where t_10m.md5 like '%cb%';
 time used (s): 10
 Nested Loop
   ->  Seq Scan on t_1m => rows 7/100 0% => blks 8334/8334 100%
   ->  Materialize => file read readptrcount=1 rows write=1189285
read=6584854 disk use (bytes) 53842965
 ->  Seq Scan on t_10m => rows 1145596/738172 155%
   Filter: (md5 ~~ '%cb%'::text)
 total disk space used (MB) 51
(9 rows)

=> Terminal 2
test=# PROGRESS (FORMAT JSON) 9546;
PLAN PROGRESS
--
 [   +
   "status": "",  +
   "query": "select * from t_10m, t_1m where t_10m.md5 like '%cb%';",+
   "time used (s)": 0,   +
   "single worker": {+
 "Node Type": "Nested Loop", +
 "Partial Mode": "", +
 "Operation": "single worker",   +
 "Parent Relationship": "single worker", +
 "Custom Plan Provider": "(@\u0004\u0001",   +
 "Parallel Aware": false,+
 "Outer": {  +
   "Node Type": "Seq Scan",  +
   "Strategy": "",   +
   "Partial Mode": "single worker",  +
   "Operation": "Outer", +
   "Parent Relationship": "Outer",   +
   "Custom Plan Provider": "(@\u0004\u0001", +
   "Parallel Aware": false,  +
   "relation": "t_1m",   +
   "rows fetched": 1,+
   "rows total": 100,+
   "rows percent": 0,+
   "blocks fetched": 8334,   +
   "blocks total": 8334, +
   "blocks percent": 100 +
 },  +
 "Inner": {  +
   "Node Type": "Materialize",   +
   "Strategy": "",   +
   "Partial Mode": "single worker",  +
   "Operation": "Inner", +
   "Parent Relationship": "Inner",   +
   "Custom Plan Provider": "(@\u0004\u0001", +
   "Parallel Aware": false,  +
   "file store": "write",+
   "readptrcount": 1,+
   "rows write": 297256, +
   "rows read": 0,   +
   "disk use (bytes)": 11911168, +
   "Outer": {+
 "Node Type": "Seq Scan",+
 "Strategy": "", +
 "Partial Mode": "Inner",+
 "Operation": "Outer",   +
 "Parent Relationship": "Outer", +
 "Custom Plan Provider": "HtFH\b[]\u000f\u001f", +
 "Parallel Aware": false,+
 "relation": "t_10m",+
 "rows fetched": 253566, +
 "rows total": 738172,   +
 "rows percent": 34, +
 "blocks fetched": 18436,+
 "blocks total": 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

[Robert Haas]

On Mon, Jul 31, 2017 at 6:10 AM, Pavel Stehule  wrote:
> you can support XML, JSON output format like EXPLAIN does.
>
>  https://www.postgresql.org/docs/current/static/sql-explain.html

+1 for that approach.
-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

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

[Pavel Stehule]

2017-07-31 11:09 GMT+02:00 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 |  concat  |  value   |  unit
>> > ---+--+-+--+--+-
>> >  14106 |0 |   4 | status   | query running|
>> >  14106 |0 |   4 | relationship | progression  |
>> >  14106 |0 |   4 |node name | Sort |
>> >  14106 |0 |   4 |sort status   | on tapes writing |
>> >  14106 |0 |   4 |completion| 0| percent
>> >  14106 |0 |   4 |relationship  | Outer|
>> >  14106 |0 |   4 |   node name  | Seq Scan |
>> >  14106 |0 |   4 |   scan on| t_10m|
>> >  14106 |0 |   4 |   fetched| 25049| block
>> >  14106 |0 |   4 |   total  | 83334| block
>> >  14106 |0 |   4 |   completion | 30   | percent
>> > (11 rows)
>> >
>> > test=#
>>
>> Somehow I imagined that the output would look more like what EXPLAIN
>> produces.
>>
>
>
> I had initially used the same output as for the ANALYZE command:
>
> test=# PROGRESS 14611;
>   PLAN PROGRESS
>
> 
> -
>  Gather Merge
>->  Sort=> dumping tuples to tapes
>  rows r/w merge 0/0 rows r/w effective 0/1464520 0%
>  Sort Key: md5
>  ->  Parallel Seq Scan on t_10m => rows 1464520/4166700 35% blks
> 36011/83334 43%
> (5 rows)
>
> test=#
>
> But this restricts the use to "human consumers". Using a table output with
> name/value pairs, allows the use by utilities for instance, without
> parsing. This is less handy for administrators, but far better for 3rd
> party utilities. One solution is otherwise to create a PL/SQL command on
> top of pg_progress() SQL function to produce an output similar to the one
> of the ANALYZE command.
>

you can support XML, JSON output format like EXPLAIN does.

 https://www.postgresql.org/docs/current/static/sql-explain.html

Regards

pavel

>
>
>> > If the one shared memory page is not enough for the whole progress
>> report,
>> > the progress report transfert between the 2 backends is done with a
>> series
>> > of request/response. Before setting the latch, the monitored backend
>> write
>> > the size of the data dumped in shared memory and set a status to
>> indicate
>> > that more data is to be sent through the shared memory page. The
>> monitoring
>> > backends get the result and sends an other signal, and then wait for the
>> > latch again. The monitored backend does not collect a new progress
>> report
>> > but continues to dump the already collected report. And the exchange
>> goes on
>> > until the full progress report has been dumped.
>>
>> This is basically what shm_mq does.  We probably don't want to
>> reinvent that code, as it has taken a surprising amount of debugging
>> to get it fully working.
>>
>
> Yes, I had once considered this solution but then moved away as I was
> unsure of the exact need for the transfert of the progress report between
> the monitored and the monitoring backends.
> I'am going to switch to shm_mq.
>
> Thx & Rgds
>
>
>
>>
>> --
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>
>

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

[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,
>> > unit FROM pg_progress(0,0);
>> >   pid  | ppid | bid |  concat  |  value   |  unit
>> > ---+--+-+--+--+-
>> >  14106 |0 |   4 | status   | query running|
>> >  14106 |0 |   4 | relationship | progression  |
>> >  14106 |0 |   4 |node name | Sort |
>> >  14106 |0 |   4 |sort status   | on tapes writing |
>> >  14106 |0 |   4 |completion| 0| percent
>> >  14106 |0 |   4 |relationship  | Outer|
>> >  14106 |0 |   4 |   node name  | Seq Scan |
>> >  14106 |0 |   4 |   scan on| t_10m|
>> >  14106 |0 |   4 |   fetched| 25049| block
>> >  14106 |0 |   4 |   total  | 83334| block
>> >  14106 |0 |   4 |   completion | 30   | percent
>> > (11 rows)
>> >
>> > test=#
>>
>> Somehow I imagined that the output would look more like what EXPLAIN
>> produces.
>>
>
> me too.
>
> Regards
>
> Pavel
>

Above output is better for utilities. No need to parse the fields. But I
can also provide a second SQL function name pg_progress_admin() with an
output similar to ANALYZE command.
Then comes an other question about the format of the output which can be
TEXT, XML, JSON or YAML as for the ANALYZE command.

An other solution is also to use a PL/SQL package to transform the
pg_progress() output into an output similar to ANALYZE command and let the
use decide which format (XML, JSON, ...) to use.

Thx & Rgds
Remi


>
>
>>
>> > If the one shared memory page is not enough for the whole progress
>> report,
>> > the progress report transfert between the 2 backends is done with a
>> series
>> > of request/response. Before setting the latch, the monitored backend
>> write
>> > the size of the data dumped in shared memory and set a status to
>> indicate
>> > that more data is to be sent through the shared memory page. The
>> monitoring
>> > backends get the result and sends an other signal, and then wait for the
>> > latch again. The monitored backend does not collect a new progress
>> report
>> > but continues to dump the already collected report. And the exchange
>> goes on
>> > until the full progress report has been dumped.
>>
>> This is basically what shm_mq does.  We probably don't want to
>> reinvent that code, as it has taken a surprising amount of debugging
>> to get it fully working.
>>
>> --
>> Robert Haas
>> EnterpriseDB: http://www.enterprisedb.com
>> The Enterprise PostgreSQL Company
>>
>>
>> --
>> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
>> To make changes to your subscription:
>> http://www.postgresql.org/mailpref/pgsql-hackers
>>
>
>

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

[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 |  concat  |  value   |  unit
> > ---+--+-+--+--+-
> >  14106 |0 |   4 | status   | query running|
> >  14106 |0 |   4 | relationship | progression  |
> >  14106 |0 |   4 |node name | Sort |
> >  14106 |0 |   4 |sort status   | on tapes writing |
> >  14106 |0 |   4 |completion| 0| percent
> >  14106 |0 |   4 |relationship  | Outer|
> >  14106 |0 |   4 |   node name  | Seq Scan |
> >  14106 |0 |   4 |   scan on| t_10m|
> >  14106 |0 |   4 |   fetched| 25049| block
> >  14106 |0 |   4 |   total  | 83334| block
> >  14106 |0 |   4 |   completion | 30   | percent
> > (11 rows)
> >
> > test=#
>
> Somehow I imagined that the output would look more like what EXPLAIN
> produces.
>


I had initially used the same output as for the ANALYZE command:

test=# PROGRESS 14611;
  PLAN
PROGRESS
-
 Gather Merge
   ->  Sort=> dumping tuples to tapes
 rows r/w merge 0/0 rows r/w effective 0/1464520 0%
 Sort Key: md5
 ->  Parallel Seq Scan on t_10m => rows 1464520/4166700 35% blks
36011/83334 43%
(5 rows)

test=#

But this restricts the use to "human consumers". Using a table output with
name/value pairs, allows the use by utilities for instance, without
parsing. This is less handy for administrators, but far better for 3rd
party utilities. One solution is otherwise to create a PL/SQL command on
top of pg_progress() SQL function to produce an output similar to the one
of the ANALYZE command.


> > If the one shared memory page is not enough for the whole progress
> report,
> > the progress report transfert between the 2 backends is done with a
> series
> > of request/response. Before setting the latch, the monitored backend
> write
> > the size of the data dumped in shared memory and set a status to indicate
> > that more data is to be sent through the shared memory page. The
> monitoring
> > backends get the result and sends an other signal, and then wait for the
> > latch again. The monitored backend does not collect a new progress report
> > but continues to dump the already collected report. And the exchange
> goes on
> > until the full progress report has been dumped.
>
> This is basically what shm_mq does.  We probably don't want to
> reinvent that code, as it has taken a surprising amount of debugging
> to get it fully working.
>

Yes, I had once considered this solution but then moved away as I was
unsure of the exact need for the transfert of the progress report between
the monitored and the monitoring backends.
I'am going to switch to shm_mq.

Thx & Rgds



>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>

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

[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,
> > unit FROM pg_progress(0,0);
> >   pid  | ppid | bid |  concat  |  value   |  unit
> > ---+--+-+--+--+-
> >  14106 |0 |   4 | status   | query running|
> >  14106 |0 |   4 | relationship | progression  |
> >  14106 |0 |   4 |node name | Sort |
> >  14106 |0 |   4 |sort status   | on tapes writing |
> >  14106 |0 |   4 |completion| 0| percent
> >  14106 |0 |   4 |relationship  | Outer|
> >  14106 |0 |   4 |   node name  | Seq Scan |
> >  14106 |0 |   4 |   scan on| t_10m|
> >  14106 |0 |   4 |   fetched| 25049| block
> >  14106 |0 |   4 |   total  | 83334| block
> >  14106 |0 |   4 |   completion | 30   | percent
> > (11 rows)
> >
> > test=#
>
> Somehow I imagined that the output would look more like what EXPLAIN
> produces.
>

me too.

Regards

Pavel


>
> > If the one shared memory page is not enough for the whole progress
> report,
> > the progress report transfert between the 2 backends is done with a
> series
> > of request/response. Before setting the latch, the monitored backend
> write
> > the size of the data dumped in shared memory and set a status to indicate
> > that more data is to be sent through the shared memory page. The
> monitoring
> > backends get the result and sends an other signal, and then wait for the
> > latch again. The monitored backend does not collect a new progress report
> > but continues to dump the already collected report. And the exchange
> goes on
> > until the full progress report has been dumped.
>
> This is basically what shm_mq does.  We probably don't want to
> reinvent that code, as it has taken a surprising amount of debugging
> to get it fully working.
>
> --
> Robert Haas
> EnterpriseDB: http://www.enterprisedb.com
> The Enterprise PostgreSQL Company
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

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

[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 |  concat  |  value   |  unit
> ---+--+-+--+--+-
>  14106 |0 |   4 | status   | query running|
>  14106 |0 |   4 | relationship | progression  |
>  14106 |0 |   4 |node name | Sort |
>  14106 |0 |   4 |sort status   | on tapes writing |
>  14106 |0 |   4 |completion| 0| percent
>  14106 |0 |   4 |relationship  | Outer|
>  14106 |0 |   4 |   node name  | Seq Scan |
>  14106 |0 |   4 |   scan on| t_10m|
>  14106 |0 |   4 |   fetched| 25049| block
>  14106 |0 |   4 |   total  | 83334| block
>  14106 |0 |   4 |   completion | 30   | percent
> (11 rows)
>
> test=#

Somehow I imagined that the output would look more like what EXPLAIN produces.

> If the one shared memory page is not enough for the whole progress report,
> the progress report transfert between the 2 backends is done with a series
> of request/response. Before setting the latch, the monitored backend write
> the size of the data dumped in shared memory and set a status to indicate
> that more data is to be sent through the shared memory page. The monitoring
> backends get the result and sends an other signal, and then wait for the
> latch again. The monitored backend does not collect a new progress report
> but continues to dump the already collected report. And the exchange goes on
> until the full progress report has been dumped.

This is basically what shm_mq does.  We probably don't want to
reinvent that code, as it has taken a surprising amount of debugging
to get it fully working.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers