On Tue, May 10, 2016 at 3:42 PM, Konstantin Knizhnik <k.knizh...@postgrespro.ru> wrote: > Doesn't this actually mean that we need to have normal job scheduler which > is given queue of jobs and having some pool of threads will be able to > orginize efficient execution of queries? Optimizer can build pipeline > (graph) of tasks, which corresponds to execution plan nodes, i.e. SeqScan, > Sort, ... Each task is splitted into several jobs which can be concurretly > scheduled by task dispatcher. So you will not have blocked worker waiting > for something and all system resources will be utilized. Such approach with > dispatcher allows to implement quotas, priorities,... Also dispatches can > care about NUMA and cache optimizations which is especially critical on > modern architectures. One more reference: > http://db.in.tum.de/~leis/papers/morsels.pdf
I read this as a proposal to redesign the entire optimizer and executor to use some new kind of plan. That's not a project I'm willing to entertain; it is hard to imagine we could do it in a reasonable period of time without introducing bugs and performance regressions. I think there is a great deal of performance benefit that we can get by changing things incrementally. -- 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
