Re: Asynchronous Append on postgres_fdw nodes.
От | Craig Ringer |
---|---|
Тема | Re: Asynchronous Append on postgres_fdw nodes. |
Дата | |
Msg-id | CAGRY4nyCMHQ3BzWSN6mZPmX2RioL1Ce3JAqYibPOiPTS1be2Kg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Asynchronous Append on postgres_fdw nodes. ("movead.li@highgo.ca" <movead.li@highgo.ca>) |
Список | pgsql-hackers |
"On Thu, Nov 26, 2020 at 9:28 AM movead.li@highgo.ca <movead.li@highgo.ca> wrote: > > > I test the patch and occur several issues as blow: > > Issue one: > Get a Assert error at 'Assert(bms_is_member(i, node->as_needrequest));' in > ExecAppendAsyncRequest() function when I use more than two foreign table > on different foreign server. > > I research the code and do such change then the Assert problem disappear. > > @@ -1004,6 +1004,7 @@ ExecAppendAsyncResponse(AsyncRequest *areq) bms_del_member(node->as_needrequest, areq->request_index);node->as_asyncpending = bms_add_member(node->as_asyncpending, areq->request_index); + node->as_lastasyncplan= INVALID_SUBPLAN_INDEX; return false; } > > Issue two: > Then I test and find if I have sync subplan and async sunbplan, it will run over > the sync subplan then the async turn, I do not know if it is intent. I only just noticed this patch. It's very interesting to me given the ongoing work happening on postgres_fdw batching and the way libpq pipelining is looking like it's getting there. I'll study up on the executor and see if I can understand this well enough to hack together a PoC to make it use libpq batching. Have you taken a look at how this patch may overlap with those? See -hackers threads: * "POC: postgres_fdw insert batching" [1] * "PATCH: Batch/pipelining support for libpq" [2] [1] https://www.postgresql.org/message-id/OSBPR01MB2982039EA967F0304CC6A3ECFE0B0@OSBPR01MB2982.jpnprd01.prod.outlook.com [2] https://www.postgresql.org/message-id/20201026190936.GA18705@alvherre.pgsql
В списке pgsql-hackers по дате отправления: