On Fri, Feb 11, 2011 at 6:40 PM, Nick Rudnick <joerg.rudn...@t-online.de> wrote: > I remember well PostgreSQL has an own garbage collection (palloc() etc.;I > only know it is in utils of the backend, at mmgr), but I didn't find it on > the TODO list; so > > o would you say "hands off the garbage collection" or could you imagine > extensions? > > o would you consider the PostgreSQL garbage collection to be rather > specific (e.g., DBMS specific optimizations) or heavily interwoven into the > code -- or could it be conceivable that behaviour requirements from > PostgreSQL could be specified so far that alternative garbage collections > can be developed and inserted?
Despite occasional posturing, I think that our community tends to take a pretty pragmatic view of the world. If a patch can be shown to have more upside than downside, we tend to accept it. If it has more downside than upside, we reject it. Now, I think all of us have lists of things that we're most interested in working on, based on the problems that we encounter in real life. I worked on join removal because it solved particular problems that I ran into when building web applications. Greg Smith works on checkpointing and other issues related to disk I/O because he helps people build big honking servers that use PostgreSQL, and that's where he runs into problems. Kevin Grittner implemented SSI for true serializability because it solves a problem he has. If you're fired up about improving memory management, by all means have a crack at it. As an armchair quarterback, I'm a bit doubtful that there is a significant amount of efficiency or maintainability that can be squeezed out of that subsystem, but I'd be happy to be proven wrong. There are certainly workloads where palloc overhead is significant, and if someone can find a way to make a meaningful improvement there, we're not going to reject it because we didn't think of it ourselves. > Time for a 'coming out': In the last years, I have mostly worked with pure > typed declarative languages (Haskell, Mercury), so I personally have a type > system like Hindley-Milner in mind, which by concept does not have infinite > pointer chains and also in other regards seems to be in much closer > relationship with relational database systems (an interesting, though early > state effort: http://groups.inf.ed.ac.uk/links/). I've been interested in this in the past, but the implementation challenges are daunting. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers