Re: CF3+4 (was Re: Parallel query execution)

On Tue, Jan 22, 2013 at 7:57 AM, Phil Sorber <phil(at)omniti(dot)com> wrote:
> On Mon, Jan 21, 2013 at 8:47 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
>>> My own experience is different from yours, I guess. I actually like
>>> it when I post a patch, or suggest a concept, and Tom fires back with
>>> a laundry list of reasons it won't work.
>>
>> This can be a problem with new submitters, though. If you're not used
>> to the current community dialog, that email can be taken as "your idea
>> is stupid because" rather than what it actually means, which is "fix
>> these issues and resubmit, please". That's often not clearly
>> communicated, and is important with new submitters.
>>
>
> +1 to this as well. I definitely felt that way when submitting my
> first patch. Robert might even recall a convo at a conference that he
> and I had about it. If not for that I might have given up long ago.
> Now I can say I am used to it though, and I appreciate the honest and
> constructive criticism I receive because over time I have seen that
> Tom and others are even critical of themselves and it's really for the
> betterment of the final product.

For me our reluctance for any kind of change is a major demoralizing
factor. For example, the recent discussion on Jeff Davis's patch on
PD_ALL_VISIBLE flag. Our committers are quite candid in accepting that
they may not have put in so much thought or did any real testing while
adding the original code, but when it comes to making a change we show
reluctance, ask for several test results and the patch author really
needs to show extra worth for the change. That looks a bit unfair
because the original code may not have received the same attention.
Though I completely understand that the committers usually have a
better sense and gut feel. If Heikki had not put that page level flag
in the first place and if someone would have suggested adding that
flag today, my sense is that we would have pushed him/her back and
asked for many explanations like why waste a bit in the page or the
performance increase is just 10% and that too in the worst case, so
not worth it. Another example is the SKIP_PAGES_THRESHOLD in
vacuumlazy.c. I'm quite convinced that the current default of 32 is
quite arbitrary and the entire logic to not skip heap pages unless
there are 32 in sequence is hard to justify, but if that needs to be
changed, we would need hours of testing to show its worth. (BTW, I
know both these changes are probably committed by Heikki. But thats
just a coincidence :-) I've great respect for Heikki's talent and he
is often right in his judgement)

Having said that, I quite understand the reasoning behind the
reluctance for change - we are a small community and can't afford to
spend cycles spending on unnecessary regressions. But is that changing
in the recent years ? I mean, aren't there a lot more developers and a
lot more companies using/testing the new features/releases and
reporting issues ? I see a marked increase in the number of bugs
reported (haven't really counted but just observation and it could be
wrong). Not sure if its a result of increased testing/adaption or a
slight drop in the quality or just because of the sheer increase in
the number of features/changes we are doing.

Thanks,
Pavan

--
Pavan Deolasee
http://www.linkedin.com/in/pavandeolasee