On Tue, Jul 25, 2017 at 5:11 AM, Kyotaro HORIGUCHI <horiguchi.kyot...@lab.ntt.co.jp> wrote: > [ new patches ]
I spent some time today refreshing my memory of what's going with this thread today. Ostensibly, the advantage of this framework over my previous proposal is that it avoids inserting anything into ExecProcNode(), which is probably a good thing to avoid given how frequently ExecProcNode() is called. Unless the parent and the child both know about asynchronous execution and choose to use it, everything runs exactly as it does today and so there is no possibility of a complaint about a performance hit. As far as it goes, that is good. However, at a deeper level, I fear we haven't really solved the problem. If an Append is directly on top of a ForeignScan node, then this will work. But if an Append is indirectly on top of a ForeignScan node with some other stuff in the middle, then it won't - unless we make whichever nodes appear between the Append and the ForeignScan async-capable. Indeed, we'd really want all kinds of joins and aggregates to be async-capable so that examples like the one Corey asked about in http://postgr.es/m/CADkLM=fuvVdKvz92XpCRnb4=rj6bLOhSLifQ3RV=sb4q5rj...@mail.gmail.com will work. But if we do, then I fear we'll just be reintroducing the same performance regression that we introduced by switching to this framework from the previous one - or maybe a different one, but a regression all the same. Every type of intermediate node will have to have a code path where it uses ExecAsyncRequest() / ExecAyncHogeResponse() rather than ExecProcNode() to get tuples, and it seems like that will either end up duplicating a lot of code from the regular code path or, alternatively, polluting the regular code path with some of the async code's concerns to avoid duplication, and maybe slowing things down. Maybe that concern is unjustified; I'm not sure. Thoughts? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
