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