On Mon, May 10, 2021 at 8:45 PM Andrey Lepikhov <a.lepik...@postgrespro.ru> wrote:
> On 7/5/21 21:05, Etsuro Fujita wrote: > > I think it would be better to start a new thread for this, and add the > > patch to the next CF so that it doesn’t get lost. > > Current implementation of async append choose asynchronous subplans at > the phase of an append plan creation. This is safe approach, but we > loose some optimizations, such of flattening trivial subqueries and > can't execute some simple queries asynchronously. For example: > > EXPLAIN (ANALYZE, TIMING OFF, SUMMARY OFF, COSTS OFF) > (SELECT * FROM f1 WHERE a < 10) UNION ALL > (SELECT * FROM f2 WHERE a < 10); > > But, as I could understand, we can choose these subplans later, at the > init append phase when all optimizations already passed. > In attachment - implementation of the proposed approach. > > Initial script for the example see in the parent thread [1]. > > > [1] > > https://www.postgresql.org/message-id/a38bb206-8340-9528-5ef6-37de2d5cb1a3%40postgrespro.ru > > > -- > regards, > Andrey Lepikhov > Postgres Professional > Hi, + /* Check to see if subplan can be executed asynchronously */ + if (subplan->async_capable) + { + subplan->async_capable = false; It seems the if statement is not needed: you can directly assign false to subplan->async_capable. Cheers
