Re: Multithread Query Planner

On Fri, Jan 13, 2012 at 3:14 PM, Frederico <zepfred(at)gmail(dot)com> wrote:
> Hi folks.
>
> Is there any restriction in create and start threads inside Postgres?
>
> I'm trying to develop a multithread planner, and some times is raised a exception of access memory.
>
> I'm debugging the code to see if is a bug in the planner, but until now, I still not found. I tried to use the same memory context of root process and create a new context to each new thread, but doesn't worked.
>
>
> Any tips?

Yes, don't try to use threads.

<http://wiki.postgresql.org/wiki/Developer_FAQ#Why_don.27t_you_use_threads.2C_raw_devices.2C_async-I.2FO.2C_.3Cinsert_your_favorite_wizz-bang_feature_here.3E.3F>

... threads are not currently used instead of multiple processes for
backends because:

Historically, threads were poorly supported and buggy.
An error in one backend can corrupt other backends if they're
threads within a single process
Speed improvements using threads are small compared to the
remaining backend startup time.
The backend code would be more complex.
Terminating backend processes allows the OS to cleanly and quickly
free all resources, protecting against memory and file descriptor
leaks and making backend shutdown cheaper and faster
Debugging threaded programs is much harder than debugging worker
processes, and core dumps are much less useful
Sharing of read-only executable mappings and the use of
shared_buffers means processes, like threads, are very memory
efficient
Regular creation and destruction of processes helps protect
against memory fragmentation, which can be hard to manage in
long-running processes

There's a pretty large burden of reasons *not* to use threads, and
while some of them have diminished in importance, most have not.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"