From: | Thomas Munro <munro(at)ip9(dot)org> |
---|---|
To: | Frederico <zepfred(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Multithread Query Planner |
Date: | 2012-01-14 13:42:01 |
Message-ID: | CADLWmXVHRdB8O-ddBE0k2JiJ9jno3oUGFt5SvZZRfkpBG+O-sw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 13 January 2012 20:14, Frederico <zepfred(at)gmail(dot)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?
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2012-01-14 14:06:34 | Re: xlog location arithmetic |
Previous Message | Peter Eisentraut | 2012-01-14 13:40:08 | Re: controlling the location of server-side SSL files |