On 6/5/21 11:45, Etsuro Fujita wrote:
On Tue, Apr 27, 2021 at 9:31 PM Etsuro Fujita <etsuro.fuj...@gmail.com> wrote: The patch fixes the issue, but I don’t think it’s the right way to go, because it requires an extra ExecProcNode() call, which wouldn’t be efficient. Also, the patch wouldn’t address another issue I noticed in EXPLAIN ANALYZE for async-capable nodes that the command wouldn’t measure the time spent in such nodes accurately. For the case of async-capable node using postgres_fdw, it only measures the time spent in ExecProcNode() in ExecAsyncRequest()/ExecAsyncNotify(), missing the time spent in other things such as creating a cursor in ExecAsyncRequest(). :-(. To address both issues, I’d like to propose the attached, in which I added instrumentation support to ExecAsyncRequest()/ExecAsyncConfigureWait()/ExecAsyncNotify(). I think this would not only address the reported issue more efficiently, but allow to collect timing for async-capable nodes more accurately.
Ok, I agree with the approach, but the next test case failed:
EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)
SELECT * FROM (
(SELECT * FROM f1) UNION ALL (SELECT * FROM f2)
) q1 LIMIT 100;
ERROR: InstrUpdateTupleCount called on node not yet executed
Initialization script see in attachment.
--
regards,
Andrey Lepikhov
Postgres Professional
t1.sql
Description: application/sql
