Hi, On 2017-12-06 12:28:29 -0500, Robert Haas wrote: > > Possibly we even want to continue having various > > processes around besides that, the most interesting cases involving > > threads are around intra-query parallelism, and pooling, and for both a > > hybrid model could be beneficial. > > I think if we only use threads for intra-query parallelism we're > leaving a lot of money on the table. For example, if all > shmem-connected backends are using the same process, then we can make > max_locks_per_transaction PGC_SIGHUP. That would be sweet, and there > are probably plenty of similar things. Moreover, if threads are this > thing that we only use now and then for parallel query, then our > support for them will probably have bugs. If we use them all the > time, we'll actually find the bugs and fix them. I hope.
I think it'd make a lot of sense to go there gradually. I agree that we probably want to move to more and more use of threads, but we also want our users not to kill us ;). Initially we'd surely continue to use partitioned dynahash for locks, which'd make resizing infeasible anyway. Similar for shared buffers (which I find a hell of a lot more interesting to change at runtime than max_locks_per_transaction), etc... - Andres
