340:
user prefers the non-optimized version, overriding what they asked for is a questionable practice. Think of it like an auto-correct spellchecker in a word processor. Sure, most of the time it may make good corrections, but, on occasion, it will make a "correction" you don't want (let's say you are writing dialog and are trying to show a dialect by including words like "aint").
484:
Well, say you want your own code to be optimized, so that, if you transfer it to a different platform which does the optimization differently, you don't have to worry about it slowing down. In this case, you wouldn't want it optimizing it for you, as this would obscure the optimization level of your
353:
A possible improvement they could make in the DB2 case is to have a setting which controls whether it optimizes queries where you've intentionally asked for it to do things in an inefficient manner. Perhaps a future DB2 version could also offer an alternative to "*", meaning "all". How about "?",
339:
It is, but it's one thing when you say "retrieve whatever you need to" and quite another when you say "retrieve all this stuff you don't need". In the one case optimization is doing what you asked, while, in the other, it's going counter to what you asked. Since there might be some reason why the
238:
Various storage arrays from Oracle, IBM, Netapp, HDS, HP, and Dell use drives in flat (label side up) and on edge (label side left or right) configuration. Oracle's
Thumper and Thor arrays, which have pull-out trays, have the drives in connector-down orientation. Dell's Precision desktop machines
204:
Every modern hard drive technical spec I've ever looked at says that they can be mounted at any angle, and recommend not moving them around once they are running. That implies that if there is a slight advantadge to a particular orientation then it isn't something the manufacturer considers
380:
Would DB2 really find itself to be forced to execute the obviously inefficient query, given that there's no way a user could tell the difference by the end result (the final selected columns are the same...) - either DB2 would truly suck, or there is something much more subtle going on.
138:
External hard disk drives last longest if placed in the orientation, whether horizontal or vertical, indicated by the manufacturer's logo/label or the physical stand, since the manufacturer would have designed the hard drive to be placed in the orientation implied by that logo/label or
239:
have the drives in a connector-up orientation. So they're all orienting the disks in a way that suits their chassis, cable routing, and cooling strategy. There's no consensus orientation, because there's no advice from any HDD maker that orientation matters. --
205:
noteworthy. You could always look up the spec for your particular drive to be sure. It sounds like you're using an external drive, so the only thing I would worry about is making sure that any ventilation holes are unobstructed.
219:
I can attest to the not moving them around when connected. Mine still works perfectly fine, but I've pulled it around so much that it will often disconnect and reconnect to the computer if it even moves around a little now. -
411:
No, that does make sense; there is nothing more infuriating than something that won't let you overrule the defaults, optimizations, etc. because the designer didn't see any reason why you would ever want to.
260:
Can't seem to find the details regarding this particular db2 sql query optimization; i got told, so long ago, that the query optimizer was smart enough not to deal with unneeded columns; i.e., if i wrote
66:
51:
45:
59:
55:
186:
Also there is no friction or noticeable gravitational push pressing the heads onto the platters. They "fly" on the air drawn around by the platter which they are accessing.--
268:
it would be smart enough to just handle columns foo and foo2 from table b. Anyway, we got upgraded to version 10, and this doesn't seem to be the case; I need to specify
317:
yeah, you'd think it would be easy enough to write db2 optimizer code which could see which columns are used in the query and use that instead of the *..... oh well.
290:
Not sure, but you are explicitly asking it to return all columns from b, so I can see why they might not want to override that. It would be different if you wrote:
25:
485:
own code. Another (admittedly poor) practice might be to make it intentionally inefficient so that the data scrolls by at a slower pace which you can read.
85:
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the
161:
Google's servers use horizontally orientated drives. I think that Google would have thought about this, as they go through many, many drives.
37:
299:
In this case you don't explicitly specify to retrieve all columns from b, so it's reasonable to expect it to only fetch the ones it needs.
206:
168:
21:
142:
Hard disk drives do not last any longer or shorter based on whether they are placed in a horizontal or vertical orientation.
494:
455:
421:
390:
363:
326:
308:
284:
249:
229:
214:
195:
176:
155:
135:/resistance, since gravity is not pushing the head against the platter, nor the platter against any surface below it.
131:
External hard disk drives last longest if placed in a vertical orientation because the platter then spins with least
86:
17:
246:
210:
172:
151:
121:
109:
146:
Which of these four claims is true? How should I orient my external hard drives to maximize their lifetimes? —
275:
instead to get it to run. Was it the case that this was an optimization? Is it no longer the case? Thanks.
164:
225:
108:
I have heard four conflicting claims regarding the effect of horizontal/vertical orientation on how long
191:
240:
147:
417:
322:
280:
386:
221:
117:
490:
359:
304:
294:
SELECT a.foo, b.foo2 FROM akbar a, berny b WHERE a.foo = b.foo AND b.foo2 : -->
187:
451:
128:(that is, force exerted by gravity is always the same at every point in each spin cycle).
116:
External hard disk drives last longest if placed in a horizontal orientation because the
413:
318:
276:
382:
486:
355:
300:
447:
74:
264:
select a.foo, b.foo2 from a left join (select * from b where foo2 : -->
132:
125:
446:
I can't see why you would ever want to. Can you give an example? --
79:
Welcome to the
Knowledge (XXG) Computing Reference Desk Archives
104:Hard disk orientation to maximize device lifetime
271:... (select foo, foo2 from b where foo2 : -->
8:
49:
36:
65:
43:
112:last (that is, the device lifetime):
7:
32:
120:then spins evenly underneath the
354:meaning "just what is needed" ?
18:Knowledge (XXG):Reference desk
1:
33:
495:16:54, 6 October 2012 (UTC)
456:04:04, 5 October 2012 (UTC)
422:06:17, 4 October 2012 (UTC)
391:21:01, 3 October 2012 (UTC)
364:18:35, 3 October 2012 (UTC)
327:16:43, 3 October 2012 (UTC)
309:08:18, 3 October 2012 (UTC)
285:07:46, 3 October 2012 (UTC)
250:14:15, 3 October 2012 (UTC)
230:13:02, 3 October 2012 (UTC)
215:11:50, 3 October 2012 (UTC)
196:11:26, 3 October 2012 (UTC)
177:11:19, 3 October 2012 (UTC)
156:07:06, 3 October 2012 (UTC)
523:
110:external hard disk drives
124:under the influence of
87:current reference desk
265:0) on a.foo = b.foo
167:comment added by
93:
92:
73:
72:
514:
256:DB2 optimization
179:
75:
34:
522:
521:
517:
516:
515:
513:
512:
511:
296:
273:
266:
258:
241:Finlay McWalter
162:
106:
101:
30:
29:
28:
12:
11:
5:
520:
518:
510:
509:
508:
507:
506:
505:
504:
503:
502:
501:
500:
499:
498:
497:
469:
468:
467:
466:
465:
464:
463:
462:
461:
460:
459:
458:
433:
432:
431:
430:
429:
428:
427:
426:
425:
424:
400:
399:
398:
397:
396:
395:
394:
393:
371:
370:
369:
368:
367:
366:
346:
345:
344:
343:
342:
341:
332:
331:
330:
329:
312:
311:
293:
292:
291:
270:
263:
257:
254:
253:
252:
235:
234:
233:
232:
207:209.131.76.183
201:
200:
199:
198:
181:
180:
169:217.158.236.14
148:SeekingAnswers
144:
143:
140:
136:
129:
105:
102:
100:
97:
95:
91:
90:
82:
81:
71:
70:
64:
48:
41:
40:
38:Computing desk
31:
15:
14:
13:
10:
9:
6:
4:
3:
2:
519:
496:
492:
488:
483:
482:
481:
480:
479:
478:
477:
476:
475:
474:
473:
472:
471:
470:
457:
453:
449:
445:
444:
443:
442:
441:
440:
439:
438:
437:
436:
435:
434:
423:
419:
415:
410:
409:
408:
407:
406:
405:
404:
403:
402:
401:
392:
388:
384:
379:
378:
377:
376:
375:
374:
373:
372:
365:
361:
357:
352:
351:
350:
349:
348:
347:
338:
337:
336:
335:
334:
333:
328:
324:
320:
316:
315:
314:
313:
310:
306:
302:
298:
297:
289:
288:
287:
286:
282:
278:
269:
262:
255:
251:
248:
245:
242:
237:
236:
231:
227:
223:
218:
217:
216:
212:
208:
203:
202:
197:
193:
189:
185:
184:
183:
182:
178:
174:
170:
166:
160:
159:
158:
157:
153:
149:
141:
137:
134:
130:
127:
123:
119:
115:
114:
113:
111:
103:
98:
96:
88:
84:
83:
80:
77:
76:
68:
61:
57:
53:
47:
42:
39:
35:
27:
23:
19:
274:
267:
259:
243:
222:Purplewowies
163:— Preceding
145:
107:
94:
78:
188:Phil Holmes
99:October 3
67:October 4
50:<<
46:October 2
26:Computing
414:Gzuckier
319:Gzuckier
277:Gzuckier
165:unsigned
133:friction
24: |
22:Archives
20: |
383:Unilynx
272:0) ...
126:gravity
118:platter
89:pages.
56:October
487:StuRat
356:StuRat
301:StuRat
139:stand.
448:BenRG
152:reply
69:: -->
63:: -->
62:: -->
44:<
16:<
491:talk
452:talk
418:talk
387:talk
360:talk
323:talk
305:talk
281:talk
247:Talk
226:talk
211:talk
192:talk
173:talk
122:head
295:0;
60:Nov
52:Sep
493:)
454:)
420:)
389:)
362:)
325:)
307:)
283:)
228:)
213:)
194:)
175:)
154:)
58:|
54:|
489:(
450:(
416:(
385:(
358:(
321:(
303:(
279:(
244:ჷ
224:(
209:(
190:(
171:(
150:(
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.