On Wed, May 11, 2016 at 10:17 AM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: > Yes, I agree with you that complete rewriting of optimizer is huge project > with unpredictable influence on performance of some queries. > Changing things incrementally is good approach, but only if we are moving in > right direction. > I still not sure that introduction of async. operations is step in right > direction. Async.ops are used to significantly complicate code (since you > have to maintain state yourself). It will be bad if implementation of each > node has to deal with async state itself in its own manner.
I don't really think so. The design I've proposed makes adding asynchronous capability to a node pretty easy, with only minor changes. > My suggestion is to try to provide some generic mechanism for managing state > transition and have some scheduler which controls this process. It should > not be responsibility of node implementation to organize > asynchronous/parallel execution. Instead of this it should just produce set > of jobs which execution should be controlled by scheduler. First > implementation of scheduler can be quite simple. But later in can become > more clever: try to bind data to processors and do many other optimizations. Whereas this would require a massive rewrite. -- 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
