Re: Multithread Query Planner

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?

In response to

Browse pgsql-hackers by date

  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