On Tue, May 10, 2011 at 8:35 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Simon Riggs <simon@2ndQuadrant.com> wrote:
>> Kevin Grittner <Kevin.Grittner@wicourts.gov> wrote:
>>
>>>> ... but I share Simon's desire to see some proof before anything
>>>> gets committed.
>>>
>>> And we agree there. In fact, I can't think of anyone in the
>>> community who doesn't want to see that for *any* purported
>>> performance enhancement.
>>
>> I'm not talking about eventual commit, I'm talking about the whole
>> process of development.
>
> I'm confused -- you want to see proof that the concept works well in
> PostgreSQL before development effort on it begins? Or there is some
> alternative you would like to see pursued instead? Something else?
Well, I didn't ask for that and agree it would be foolish to demand
proof ahead of development.
I know this technique is effective in other DBMS, I just want to be
certain it will be effective for us before too much work is done. We
have the additional requirement for a crash safe vacuum map that needs
to be consulted, with possible contention effects. Sybase etc can
simply avoid the logical I/O, which is always a win, in or out of
cache. So the problem is quite different for us.
What I suggested was a assessment and benefit case because we normally
start with a problem and then work out how to solve it.
Normally, others come forward with the why? when? questions and it
feels like there's a bit of groupthink going on here. This looks to me
like its being approached like it was a feature, but it looks to me
like a possible optimisation, so suggest we treat it that way.
Out of concern, I don't want you to waste time on work that *may* not
be that useful in practice, and I don't want to miss improvements or
alternatives either.
--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
