Re: Postgres with pthread
| От | Craig Ringer |
|---|---|
| Тема | Re: Postgres with pthread |
| Дата | |
| Msg-id | CAMsr+YEwp0FCf_MC6a8u=cV_konfuJ3ndYHAptvOcr-5_EVVMQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | RE: Postgres with pthread ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>) |
| Список | pgsql-hackers |
On 7 December 2017 at 11:44, Tsunakawa, Takayuki <tsunakawa.takay@jp.fujitsu.com> wrote:
From: Craig Ringer [mailto:craig@2ndquadrant.com]
> I'd personally expect that an immediate conversion would result
> in very
> little speedup, a bunch of code deleted, a bunch of complexity
> added. And it'd still be massively worthwhile, to keep medium to
> long
> term complexity and feature viability in control.
+1
I hope for things like:
* More performance statistics like system-wide LWLock waits, without the concern about fixed shared memory size
* Dynamic memory sizing, such as shared_buffers, work_mem, maintenance_work_mem
I'm not sure how threaded operations would help us much there. If we could split shared_buffers into extents we could do this with something like dsm already. Without the ability to split it into extents, we can't do it with locally malloc'd memory in a threaded system either.
Re performance diagnostics though, you can already get a lot of useful data from PostgreSQL's SDT tracepoints, which are usable with perf and DTrace amongst other tools. Dynamic userspace 'perf' probes can tell you a lot too.
I'm confident you could collect some seriously useful data with perf tracepoints and 'perf script' these days. (BTW, I extended the https://wiki.postgresql.org/wiki/Profiling_with_perf article a bit yesterday with some tips on this).
Of course better built-in diagnostics would be nice. But I really don't see how it'd have much to do with threaded vs forked model of execution; we can allocate chunks of memory with dsm now, after all.
* Running multi-threaded components in postgres extension (is it really safe to run JVM for PL/Java in a single-threaded postgres?)
PL/Java is a giant mess for so many more reasons than that. The JVM is a heavyweight startup, lightweight thread model system. It doesn't play at all well with postgres's lightweight process fork()-based CoW model. You can't fork() the JVM because fork() doesn't play nice with threads, at all. So you have to start it in each backend individually, which is just awful.
One of the nice things if Pg got a threaded model would be that you could embed a JVM, Mono/.NET runtime, etc and have your sessions work together in ways you cannot currently sensibly do. Folks using MS SQL, Oracle, etc are pretty used to being able to do this, and while it should be done with caution it can offer huge benefits for some complex workloads.
Right now if a PostgreSQL user wants to do anything involving IPC, shared data, etc, we pretty much have to write quite complex C extensions to do it.
В списке pgsql-hackers по дате отправления: