Re: Allow progress tracking of sub-commands

Manu <manuelreyesbravo(at)gmail(dot)com> wrote:

> On Wed, Jul 22, 2026 at 11:19 PM Alberto Piai
> <alberto(dot)piai(at)gmail(dot)com> wrote:
> > Sorry, I could have been clearer. I was referring specifically to the
> > Assert(), which would be hit in the edge case you mentioned (a command
> > trying to report progress past the 2nd level of nesting).
>
> v01 fixes a case not mentioned in this thread: ANALYZE of a file_fdw
> table never shows in pg_stat_progress_analyze, on 14, 18 and master.
> It makes other cases worse, and that edge case is reachable from a
> plain trigger. I sampled both views every ~0.5 ms, on v01 and on its
> base 994f770a0fd (same as master); script and results are attached.
>
> Fixed: ANALYZE of a file_fdw table, of a partitioned table with a
> file_fdw partition, a database-wide ANALYZE, and COPY FROM whose
> trigger reads a file_fdw table.
>
> Worse:
> - COPY (SELECT a FROM ft) TO shows "COPY FROM FILE relid=ft", 0 bytes.
> The scan starts in ExecutorStart (copyto.c:1039), before COPY TO
> (copyto.c:1227); both levels are COPY, the view takes level 1
> (pgstatfuncs.c:326), and all updates go to level 2.
> - Two file_fdw scans in one statement show no row, and so does one
> scan after an EXPLAIN of another file_fdw query: file_fdw.c:721
> turns tracking off when fdw_nodes > 1, and fdw_nodes is counted at
> plan time (file_fdw.c:634).

In [1] I tried a different approach: only the progress of the actually running
command is displayed, while there's no limit on the nesting level. What do you
think about that?

Regarding the file_fdw problem, I don't have a good idea how to fix it: if
contents of two or more tables is being merge-joined, there are two or more
COPY commands running at the same time. So similar to the previous version,
the patch at least disables progress reporting if file_fdw is involved.

[1] https://www.postgresql.org/message-id/137200.1794593939%40chrudos

--
Antonin Houska
Web: https://www.cybertec-postgresql.com