Re: Postgres with pthread

On Wed, Dec 6, 2017 at 12:08 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
>> 4. Rewrite file descriptor cache to be global (shared by all threads).
>
> That one I'm very unconvinced of, that's going to add a ton of new
> contention.

It might be OK on systems where we can use pread()/pwrite().
Otherwise it's going to be terrible.

> That said, I don't think just replacing threads is the right thing. I'm
> pretty sure we'd still want to have postmaster as a separate process,
> for robustness.

+1. The tendency of the postmaster to not die has been a huge boon to
the reliability of PostgreSQL - I would not like to give that up.
MySQL ends up needing safe_mysqld to cope with this issue; our idea of
having it built into the server is better.

> 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 the biggest problem with doing this for real is that it's a huge
> project, and that it'll take a long time.

+1

> Thanks for working on this!

+1

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company