Skip site navigation (1) Skip section navigation (2)

Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Nick Rudnick <joerg(dot)rudnick(at)t-online(dot)de>
Cc: Josh Berkus <josh(at)agliodbs(dot)com>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [pgsql-general 2011-1-21:] Are there any projects interested in object functionality? (+ rule bases)
Date: 2011-02-12 04:10:27
Message-ID: AANLkTinTLs5pdEdO2=k4eB85KoH08E-o-irMmfiH5Leg@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Fri, Feb 11, 2011 at 6:40 PM, Nick Rudnick <joerg(dot)rudnick(at)t-online(dot)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

In response to

pgsql-hackers by date

Next:From: Robert HaasDate: 2011-02-12 04:20:48
Subject: Re: Replication server timeout patch
Previous:From: Tom LaneDate: 2011-02-12 03:29:36
Subject: Re: ALTER EXTENSION UPGRADE, v3

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group