Completely aside from the database issues, mapserver would need some
heavy work to make all the layer processes "independent" and amenable to
beowulf-style parallelization. It is worth noting that layers are not
really all that independant from a display point of view. If you are
drawing lake polygons on top of jurisdiction polygons, for example, you
are first drawing all the jurisdictions into the end image, then drawing
all the lakes into that image. The process of creating the final visual
product is the result of sequential application of layers. Individually
rendering then serially combining the layers may or may not be more
efficient than simply serially rendering them, depending on the render
complexity of the layers.
A little work on multi-threading mapserver on the data-access side would
not hurt though, since reading from the source data files are completely
independant actions.
As far as parallelizing database reads, Tom can correct me, but
multi-processor database systems would help (one postmaster, many
postgres's). I wonder also if a Mosix system would work as a way of
using a cluster for database work? Having the database process working
on a network mounted datastore just can't be good mojo though...
P.
Tom Lane wrote:
>
> "Jan Hartmann" <jhart@frw.uva.nl> writes:
> > cluster consists of 45 nodes, all using a shared user file system. Is it
> > possible to start up a postmaster on every node, using the same database?
>
> No.
>
> > The backend processes themselves would be completely autonomous, but they
> > would have to share their data from the same source. To simplify things,
> > only read-access is necessary.
>
> In that case, make 45 copies of the database ...
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: Have you searched our list archives?
>
> http://archives.postgresql.org
