This is a discussion on strange performance regression between 7.4 and 8.1 within the Pgsql Performance forums, part of the PostgreSQL category; --> >> I would just like to note here that this is an example of inefficient >> strategy. >> [ ...
| |||||||
| FAQ | Members List | Calendar | Search | Today's Posts | Mark Forums Read |
| ||||
| >> I would just like to note here that this is an example of inefficient >> strategy. >> [ ... ] > > > Alex may have made the correct, rational choice, given the state of > accounting at most corporations. Corporate accounting practices and > the budgetary process give different weights to cash and labor. Labor > is fixed, and can be grossly wasted without (apparently) affecting the > quarterly bottom line. Cash expenditures come directly off profits. > > It's shortsighted and irrational, but nearly 100% of corporations > operate this way. You can waste a week of your time and nobody > complains, but spend a thousand dollars, and the company president is > breathing down your neck. > > When we answer a question on this forum, we need to understand that > the person who needs help may be under irrational, but real, > constraints, and offer appropriate advice. Sure, it's good to fight > corporate stupidity, but sometimes you just want to get the system > back online. Another thing --- which may or may not apply to Alex's case and to the particular state of the thread, but it's still related and IMHO important to take into account: There may be other consrtaints that makes it impossible to even consider a memory upgrade --- for example, us (our project). We *rent* the servers from a Web hoster (dedicated servers). This particular hoster does not even offer the possibility of upgrading the hardware --- 2GB of RAM, take it r leave it. Period. In other cases, the memory upgrade has a *monthly* cost (and quite often I find it excessive --- granted, that may be just me). So, $50 or $100 per month *additional* expenses may be considerable. Now, yet another thing that you (Craig) seem to be missing: you're simply putting the expense of all this time under the expenses column in exchange for solving the particular problem --- gaining the insight on the internals and performance tuning techniques for PG may well be worth tens of thousands of dollars for his company in the future. The "quick and dirty" solution is not giving a damn about knowledge but to the ability to solve the problem at hand *now*, at whatever "petty cash cost" because it looks more cost effective (when seen from the non-irrational accounting point of view, that is) --- but isn't going for the "quick and dirty" solution without learning anything from the experience also shortsighted ??? Carlos -- ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org |
| |||
| Ron wrote: > > Speak Their Language (tm) [ ... ] Do The Right Thing (tm) > [...] Not Listening to Reason (tm), > [...] > > fiscal or managerial irresponsibility.) And *here*, of all the instances, you don't put a (TM) sign ??!!!! Tsk-tsk-tsk :-) Carlos -- ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings |
| ||||
| Carlos, > Now, yet another thing that you (Craig) seem to be missing: you're > simply putting the expense of all this time under the expenses column > in exchange for solving the particular problem... More like I was trying to keep my response short ;-). I think we're all in agreement on pretty much everything: 1. Understand your problem 2. Find potential solutions 3. Find the technical, economic AND situational tradeoffs 4. Choose the best course of action My original comment was directed at item #3. I was trying to remind everyone that a simple cost analysis may point to solutions that simply aren't possible, given business constraints. I know we also agree that we should constantly fight corporate stupidity and short-sighted budgetary oversight. But that's a second battle, one that goes on forever. Sometimes you just have to get the job done within the current constraints. 'Nuff said. Craig ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to majordomo@postgresql.org so that your message can get through to the mailing list cleanly |