Re: Asynchronous Append on postgres_fdw nodes.

At Wed, 10 Feb 2021 21:31:15 +0900, Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)com> wrote in
> On Wed, Feb 10, 2021 at 7:31 PM Etsuro Fujita <etsuro(dot)fujita(at)gmail(dot)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