Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Joshua D. Drake wrote: >> Well I think that we do take performance into account. I agree >> that we should *never* have a regression in performance from release >> to release, which is what I believe has inspired this thread. > Hmm. I have developed several features that have driven performance > down. Even changes that are not feature additions but intended solely to improve performance may have corner cases where they are losses rather than wins. I think "*never* have a regression in performance" is not only pie-in-the-sky but would be a bad policy to adopt, because it would mean for instance that we couldn't intentionally optimize common cases at the expense of uncommon ones. However, I think everybody agrees that getting blindsided by unexpected performance dropoffs is a bad thing. We really need to reinstitute the sort of daily (or near-daily) performance tracking that Mark Wong used to be doing, and extend it to cover a wider variety of test cases than just DBT-2. As an example, I'll bet that this issue of operator lookup speed would never have been visible at all in DBT-2. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

Andrew Dunstan <andrew@dunslane.net> writes: > Simon Riggs wrote: >> Should we do this as part of core, or as a separate pgfoundry project? > Core, please. This is mainline -hackers material. Huh? The buildfarm isn't in core, why would a performfarm be? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster

Andrew Dunstan <andrew@dunslane.net> writes: > Josh Berkus wrote: >> ... DW operations aren't >> really testable without 18 hours to generate data ... but we could test a >> lot of things. > Performance isn't just about humungous DW apps. Indeed. I think the real take-home lesson from these past few days' discussion is that *any* particular view of performance is going to miss things that don't affect that case, but do affect somebody else. What I find most worrisome about the notion of setting up a performance-farm is that it will encourage us to optimize with blinkers on --- that is, that we will consider only the specific cases measured by whatever tests are included in the farm, and will happily pessimize other cases. We can ameliorate that a bit if we can get a sufficiently wide variety of test cases, but it will always be a concern. And dogmatic positions like "only cases involving terabytes of data are worth testing" are definitely not going to help. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings