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
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