Re: [pgsql-advocacy] Increased company involvement

On Mon, May 02, 2005 at 12:39:27PM -0500, Dave Held wrote:
> > -----Original Message-----
> > From: Bruce Momjian [mailto:pgman@candle.pha.pa.us]
> > Sent: Monday, May 02, 2005 12:17 PM
> > To: PostgreSQL advocacy
> > Cc: Dave Held; PostgreSQL-development
> > Subject: Re: [pgsql-advocacy] [HACKERS] Increased company involvement
> >
> > > [...]
> > > Really?  You have a different perspective than I see.  I have
> > > seen patches be accepted that had no core buy-in.  We accept
> > > patches based on group feedback, not some closed approval
> > > process.
> >
> > Let me also ask for you to provide an example of the behavior you
> > describe.
>
> Well, I think there's numerous examples where someone suggests some
> feature or idea, and Tom or one or two other core developers will
> say: "I don't like that idea", and then the proposer will more or
> less give up on it because it is clear that it won't go anywhere.
> So whether the process gets stopped at the patch submission level
> or the feature proposal level isn't really relevant.  It seems pretty
> clear that a handful of people decide the direction of Postgres,
> and everyone else can either contribute to the features that have
> been agreed to be acceptable and relevant, or they can fork their
> own version.

I don't think it's valid to attribute this to the core team at all, but
I do understand what you're saying. Part of this is that many people
like to see data to back up a claim before adding complexity to the
database. The current read-only table discussion is a good example. How
much will it actually help to have a means to reduce the size of
HeapHeaderData? The problem is many times it's very hard to come up with
this data without actually coding something up and trying it. As Josh B.
pointed out in another post, sometimes people will suggest something on
-hackers and it just dies on the vine. This doesn't mean it wouldn't be
useful, it means no one on hackers was interested. But for every user
who's on hackers there's probably 10 than aren't and who knows how many
who might become users if some feature was added.

Personally, I think that the current process could do a better job of
gauging how much user interest there is in changes that are in the gray
area between 'wow, that's a great idea!' and 'wow, that's a horrid
idea!'. There's also the issue of people making suggestions to try and
address a larger problem. I think read-only tables is a good example;
the real issue is that in many data-mining applications the 30 byte
overhead on tuples is huge, and puts postgresql at a big disadvantage.
Read-only tables would definately be difficult to implement, but they
*could* provide a tremendous benefit to PostgreSQL performance in
certain applications. Of course, there's other changes that could also
provide benefits, such as a means to keep a table clustered (or nearly
clustered). But these things have generally been shot-down in the past,
and the data warehousing disadvantage continues.

Now I'm not suggesting that the process is seriously broken, but I do
think that the interests and experiences of the most active developers
tend to keep us away from changes that would only help a subset of users
(or potential users). I also think it would be better if that subset was
heard better. Data warehousing is the current example that comes to
mind, but I'm certain there are others.
--
Jim C. Nasby, Database Consultant               decibel@decibel.org
Give your computer some brain candy! www.distributed.net Team #1828

Windows: "Where do you want to go today?"
Linux: "Where do you want to go tomorrow?"
FreeBSD: "Are you guys coming, or what?"