Re: Asynchronous Append on postgres_fdw nodes.

At Wed, 10 Feb 2021 21:31:15 +0900, Etsuro Fujita <etsuro.fujita@gmail.com> wrote in 
> On Wed, Feb 10, 2021 at 7:31 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
> > Attached is an updated version of the patch.  Sorry for the delay.
> 
> I noticed that I forgot to add new files.  :-(.  Please find attached
> an updated patch.

Thanks for the new version.

It seems too specific to async Append so I look it as a PoC of the
mechanism.

It creates a hash table that keyed by connection umid to record
planids run on the connection, triggerd by core planner via a dedicate
API function.  It seems to me that ConnCacheEntry.state can hold that
and the hash is not needed at all.

| postgresReconsiderAsyncForeignScan(ForeignScanState *node, AsyncContext *acxt)
| {
| ...
|     /*
|      * If the connection used for the ForeignScan node is used in other parts
|      * of the query plan tree except async subplans of the parent Append node,
|      * disable async execution of the ForeignScan node.
|      */
|     if (!bms_is_subset(fsplanids, asyncplanids))
|         return false;

This would be a reasonable restriction.

|     /*
|      * If the subplans of the Append node are all async-capable, and use the
|      * same connection, then we won't execute them asynchronously.
|      */
|     if (requestor->as_nasyncplans == requestor->as_nplans &&
|         !bms_nonempty_difference(asyncplanids, fsplanids))
|         return false;

It is the correct restiction?  I understand that the currently
intending restriction is one connection accepts at most one FDW-scan
node. This looks somethig different...

(Sorry, time's up for now.)

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center