RE: Postgres with pthread - Mailing list pgsql-hackers

From Tsunakawa, Takayuki
Subject RE: Postgres with pthread
Date
Msg-id 0A3221C70F24FB45833433255569204D1F847C0E@G01JPEXMBYT05
Whole thread Raw
In response to Re: Postgres with pthread  (Craig Ringer <craig@2ndquadrant.com>)
Responses Re: Postgres with pthread  (Craig Ringer <craig@2ndquadrant.com>)
List pgsql-hackers
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
* Running multi-threaded components in postgres extension (is it really safe to run JVM for PL/Java in a
single-threadedpostgres?)
 

Regards
Takayuki Tsunakawa



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: Postgres with pthread
Next
From: Craig Ringer
Date:
Subject: Re: Postgres with pthread