Re: Asynchronous Append on postgres_fdw nodes.

On 10/5/21 08:03, Etsuro Fujita wrote:
> On Fri, May 7, 2021 at 7:32 PM Andrey Lepikhov
> I think a simple fix for this would be just remove the check whether
> the instr->running flag is set or not in InstrUpdateTupleCount().
> Attached is an updated patch, in which I also updated a comment in
> execnodes.h and docs in fdwhandler.sgml to match the code in
> nodeAppend.c, and fixed typos in comments in nodeAppend.c.
Your patch fixes the problem. But I found two more problems:

EXPLAIN (ANALYZE, COSTS OFF, SUMMARY OFF, TIMING OFF)


SELECT * FROM (


(SELECT * FROM f1)


UNION ALL


(SELECT * FROM f2)


UNION ALL


(SELECT *
FROM l3)

) q1
LIMIT 6709;
QUERY PLAN
--------------------------------------------------------------
Limit (actual rows=6709 loops=1)
-> Append (actual rows=6709 loops=1)
-> Async Foreign Scan on f1 (actual rows=1 loops=1)
-> Async Foreign Scan on f2 (actual rows=1 loops=1)
-> Seq Scan on l3 (actual rows=6708 loops=1)

Here we scan 6710 tuples at low level but appended only 6709. Where did
we lose one tuple?

2.
SELECT * FROM (
(SELECT * FROM f1)


UNION ALL
(SELECT * FROM f2)


UNION ALL
(SELECT * FROM f3 WHERE a > 0)
) q1 LIMIT 3000;
QUERY PLAN
--------------------------------------------------------------
Limit (actual rows=3000 loops=1)
-> Append (actual rows=3000 loops=1)
-> Async Foreign Scan on f1 (actual rows=0 loops=1)
-> Async Foreign Scan on f2 (actual rows=0 loops=1)
-> Foreign Scan on f3 (actual rows=3000 loops=1)

Here we give preference to the synchronous scan. Why?

--
regards,
Andrey Lepikhov
Postgres Professional