Re: Proposal: Progressive explain

On 3/26/25 22:57, Rafael Thofehrn Castro wrote:
> So implementation was done based on transaction nested level. Cleanup is 
> only
> performed when AbortSubTransaction() is called in the same transaction 
> nested
> level as the one where the query is running. This covers both PL/pgSQL 
> exception
> blocks and savepoints.
Thanks for your efforts!
Let me provide an alternative view of your code.
Postgres has a massive gap between the start of the execution and the 
end. All the stuff that happens at that time can't be discovered. That's 
sad. If you add a new hook into the ExecuteNode (it may be designed as a 
pointer in the PlanState to affect only necessary nodes), you may push 
the code out of the core and give other extensions additional tools.
I see your reasoning here [1], but I think with the commit 4fd02bf7cf9, 
it should be revised.
As I see after reviewing your code, to design it as an extension, some 
parallel query execution stuff needs to be exported, and Instrumentation 
needs to be changed a little. For example, with progressive explain we 
have a new node state - 'not visited yet' that is different from 'not 
executed'.
What is the purpose of a new hook from a broad perspective? I designed 
at least two features with such a hook in the Postgres fork: 1) 
real-time execution statistics and 2) query interruption on the 
arbitrary trigger (planning error detected, a signal arrived, too much 
temp memory allocated, etc.). I am not sure if it would be interesting 
for the community, but when a query is executed for more than one 
minute, I certainly want to control what is happening and have some 
tools except query abortion.
The benefit of such an approach is that it is doable to change the 
Instrumentation, add a hook now, and develop this extension without a 
rush until it is stable - I think at least the case of parallel 
execution may be enhanced.

[1] 
https://www.postgresql.org/message-id/CAG0ozMrtK_u8Uf5KNZUmRNuMphV5tnC5DEhRBNRGK%2BK4L506xw%40mail.gmail.com

-- 
regards, Andrei Lepikhov