On Tue, May 10, 2011 at 8:35 PM, Kevin Grittner <kevin.gritt...@wicourts.gov> wrote: > Simon Riggs <si...@2ndquadrant.com> wrote: >> Kevin Grittner <kevin.gritt...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
