Re: Multithread Query Planner - Mailing list pgsql-hackers

From Thomas Munro
Subject Re: Multithread Query Planner
Date
Msg-id CADLWmXVHRdB8O-ddBE0k2JiJ9jno3oUGFt5SvZZRfkpBG+O-sw@mail.gmail.com
Whole thread Raw
In response to Multithread Query Planner  (Frederico <zepfred@gmail.com>)
List pgsql-hackers
On 13 January 2012 20:14, Frederico <zepfred@gmail.com> wrote:
> I'm trying to develop a multithread planner, and some times is raised a exception of access memory.

I was a bit confused about what you are trying to do -- somehow
use concurrency during the planning phase, or during
execution (maybe having produced concurrency-aware plans)?

Here is my naive thought: Since threads are not really an option
as explained by others, you could use helper processes to
implement executor concurrency, by replacing nodes with proxies
that talk to helper processes (perhaps obtained from a
per-cluster pool).  The proxy nodes would send their child
subplans and the information needed to get the appropriate
snapshot, and receive tuples via some kind of IPC (perhaps
shmem-backed queues or pipes or whatever).

A common use case in other RDBMSs is running queries over
multiple partitions using parallelism.  In the above scheme that
could be done if the children of Append nodes were candidates for
emigration to helper processes.  OTOH there are some plans
produced by UNION and certain kinds of OR that could probably
benefit.

There may be some relevant stuff in PostgreSQL-XC?


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: controlling the location of server-side SSL files
Next
From: Fujii Masao
Date:
Subject: Re: xlog location arithmetic