I'm not particularly familiar with the codebase of either PostgreSQL
or GHC, but I'd be rather surprised that porting GHC's garbage
collector to PostgreSQL would be an easy or worthwhile task. For
example, GHC's garbage collector understands the memory layout that
its data structures use, which I'm sure is rather different from the
memory layout of PostgreSQL's data structures.Also, often these
kinds of projects turn out to be busts; for example, the GHC team
worked on integrating Hugs into GHC for a while, but after some
effort decided that it would be a lot easier to write an interpreter
from scratch instead, which became ghci.
What would be far more likely to turn out to be realistic, would be
to understand GHC's garbage collector and use (some of) it's ideas
when writing a replacement garbage collector for PostgreSQL.
However, there is a lot of variation in garbage collectors because
different techniques are suited to different patterns of memory
allocation. And based on the observation that PostgreSQL makes
reasonably effective usage of virtual memory, whereas GHC's garbage
collector thrashes Virtual Memory, I would bet there is a fair
number of important differences in the systems.
Best,
Leon
On Tue, Feb 22, 2011 at 7:25 PM, Nick Rudnick joerg.rudn...@t-online.de wrote:
Dear all,
recently, at an email conversation with pgsql hackers I had a quick shot,
asking about their position to somebody replacing their palloc GC -- having
roughly in mind that either here or on a Mercury mailing list (where there's
a similar case with a pure declarative language and a Boehm GC), where there
was a conclusion a non-pure GC would be a major hindrance to deeper
interaction.
Ok, I found the answer worth a discussion here; as far as I understood, they
don't oppose the idea that the PostgreSQL GC might be a candidate for an
update. I see three issues:
(a) The most open question to me is the gain from the Haskell perspective;
most critical: Would a Haskell GC inside PostgreSQL mean a significant
change or rather a drop in the bucket? Once this may be answered
optimistically, there comes the question about possible applications --
i.e., what can be done with such a DBMS system. Knowing about efforts like
(http://groups.inf.ed.ac.uk/links/) I would like to let this open for
discussion.
Let me please drop here a quote that I believe their object relational
efforts seem to have gotten stuck at PostgreSQL due to the conceptual clash
of OO with the relational algebra underlying PostgreSQL -- which in turn
seems to harmonize much better with Hindley-Milner Co. (System F??)
(b) The question I personally can say least about are the expenditures to be
expected for a such project. I would be very interested in some statements.
I have limited knowledge about the PostgreSQL GC and would assume it is much
simpler than, e.g. the GHC GC.
(c) Gain from PostgreSQL perspective: This IMO should be answered easiest,
hoping the Haskell GC experts to be able to answer easily how much is the
overhead to be payed for pure declarativity, and the chances (e.g.
parallelism, multi cores??), too.
Besides it might be interesting to see inhowfar a considerable overhead
problem may be alleviated by a 'plugin' architecture allowing future
PostgreSQL users to switch between a set of GCs.
I would be very interested about any comments, Cheers, Nick
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
