On Wed, May 10, 2017 at 10:05 PM, Michael Paquier
<michael.paquier@gmail.com> 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 with a command-type-specific
interpretation, but for *query* progress reporting, we really need a
richer model. A query plan can contain an unbounded number of
executor nodes and Remi's idea is, quite reasonably, to report
something about each one.
From a design point of view, I think a patch like this has to clear a
number of hurdles. It needs to:
1. Decide what data to expose. The sample output looks reasonable in
this case, although the amount of code churn looks really high.
2. Find a way to advertise the data that it exposes. This patch looks
like it allocates a half-MB of shared memory per backend and gives up
if that's not enough.
3. Find a way to synchronize the access to the data that it exposes.
This patch ignores that problem completely, so multiple progress
report commands running at the same time will behave unpredictably.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
