From: Ashutosh Bapat <ashutosh.bapat....@gmail.com> > parallelism here has both pros and cons. If one of the servers errors > out while preparing for a transaction, there is no point in preparing > the transaction on other servers. In parallel execution we will > prepare on multiple servers before realising that one of them has > failed to do so. On the other hand preparing on multiple servers in > parallel provides a speed up.
And pros are dominant in practice. If many transactions are erroring out (during prepare), the system is not functioning for the user. Such an application should be corrected before they are put into production. > But this can be an improvement on version 1. The current approach > doesn't render such an improvement impossible. So if that's something > hard to do, we should do that in the next version rather than > complicating this patch. Could you share your idea on how the current approach could enable parallelism? This is an important point, because (1) the FDW may not lead us to a seriously competitive scale-out DBMS, and (2) a better FDW API and/or implementation could be considered for non-parallel interaction if we have the realization of parallelism in mind. I think that kind of consideration is the design (for the future). Regards Takayuki Tsunakawa
