From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Postgres with pthread |
Date: | 2017-12-06 17:42:08 |
Message-ID: | 20171206174208.obgkuhbf5jbpgrv7@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2017-12-06 17:56:53 | Re: Usage of epoch in txid_current |
Previous Message | Robert Haas | 2017-12-06 17:28:29 | Re: Postgres with pthread |