Re: On status data and summaries - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: On status data and summaries
Date
Msg-id 200610112226.k9BMQol07648@momjian.us
Whole thread Raw
In response to On status data and summaries  (Andrew Sullivan <ajs@crankycanuck.ca>)
Responses Re: On status data and summaries  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-hackers
Funny, sounds like what I usually do.  I welcome the assistance.

---------------------------------------------------------------------------

Andrew Sullivan wrote:
> Hello,
> 
> In a possible moment of insanity, in 
> 
> <http://archives.postgresql.org/pgsql-hackers/2006-09/msg00579.php>
> 
> I volunteered to try to help solve a problem Tom Lane noted: "The
> hard part of this problem is finding a convenient way to capture
> status data out of the community's conversations."  I observed
> that companies who do this well actually employ people to do that
> sort of thing, and that this might be a way for code morons like
> yours truly to make a contribution to development.
> 
> I've been struggling since then, trying to figure out where to start. 
> There are a _lot_ of discussions on -hackers, and many of them are
> blind alleys.  Moreover, I can't summarise everything, I don't think,
> and still make any of those summaries sufficiently detailed to allow
> them to be useful.  So I have a proposal.
> 
> I was thinking of tracking 3 or 4 such discussions in the next
> release cycle, as a kind of proof of concept.  I'm willing to do
> that, but I'd need guidance from those who are trying to produce a
> complicated feature, telling me that they need the support. 
> Therefore, if someone involved in some such discussion pokes me
> saying, "Follow this thread, please", I'll follow the thread in
> question (as well as follow-up discussions that come of it), and
> produce regular (weekly?) summaries of what I take to be the state of
> the collective mind, until such time as the code supporting the
> feature is checked in and agreed to.  Then, at release time, the
> developers can evaluate whether the tracking produced few surprises
> at the end (and, perhaps, less thrash), or whether the experiment did
> not provide any benefit.  If it does, we can see whether we can make
> this sort of thing scale by adding some additional volunteers to do a
> similar job in future.
> 
> Does that seem worth doing?  
> 
> A
> 
> -- 
> Andrew Sullivan  | ajs@crankycanuck.ca
> "The year's penultimate month" is not in truth a good way of saying
> November.
>         --H.W. Fowler
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match

--  Bruce Momjian   bruce@momjian.us EnterpriseDB    http://www.enterprisedb.com
 + If your life is a hard drive, Christ can be your backup. +


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [COMMITTERS] pgsql: Repair incorrect check for coercion
Next
From: Kai-Uwe Sattler
Date:
Subject: Re: Index Tuning Features [2]