Re: Parallell Optimizer

From: Hannu Krosing <hannu(at)2ndQuadrant(dot)com>
To: Fred&Dani&Pandora&Aquiles <fred(at)nti(dot)ufop(dot)br>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Parallell Optimizer
Date: 2013-06-11 07:24:45
Message-ID: 51B6D0BD.7070303@2ndQuadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 06/10/2013 10:37 PM, Fred&Dani&Pandora&Aquiles wrote:
> Hi,
>
>
> >> I asked a while ago in this group about the possibility to
> implement a
> >> parallel planner in a multithread way, and the replies were
> that the
> >> proposed approach couldn't be implemented, because the postgres
> is not
> >> thread-safe. With the new feature Background Worker Processes, such
> >> implementation would be possible?
>
>
> Well, there are versions of genetic algorithms that use the concept of
> islands in which the populations evolve in parallel in the different
> islands and allows interaction between the islands and so on. I'm
> working in an algorithm based on multiagent systems. At the present
> moment, I mean in H2, the agents are threads, there are a few locks
> related to agents solutions, and a few locks for the best current
> solution in the environment where the agents are 'running'. The agents
> can exchange messages with a purpose. The environment is shared by the
> all agents and they use the environment to get informations from
> another agents (current solution for example), tries to update the
> best current solution and so on.
If you do this as an academic exercise, then I'd recommend thinking in
"messages" only.

Separate out the message delivery entirely from your core design.

This makes the whole concept much simpler and more generic.

Message delivery can be made almost instantaneous in case of threads
or to take a few tens of microseconds to several seconds
between different physical nodes

Which speed is "fast enough" depends entirely on your query - for a query
running 5 hours on single CPU and 5 minutes on a cluster, message
delay of 50 ms is entirely acceptable

--
Hannu Krosing
PostgreSQL Consultant
Performance, Scalability and High Availability
2ndQuadrant Nordic OÜ

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavel Stehule 2013-06-11 07:30:32 Re: DO ... RETURNING
Previous Message Dean Rasheed 2013-06-11 07:07:23 Re: how to find out whether a view is updatable