On Wed, May 10, 2017 at 10:05 PM, Michael Paquier <michael.paqu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
