Skip site navigation (1) Skip section navigation (2)

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: (view raw, whole thread or download thread mbox)
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

There may be some relevant stuff in PostgreSQL-XC?

In response to

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2012-01-14 14:06:34
Subject: Re: xlog location arithmetic
Previous:From: Peter EisentrautDate: 2012-01-14 13:40:08
Subject: Re: controlling the location of server-side SSL files

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group