>It’s knowing how indexes work and having the intuition to create the best indexes for your queries and your data set. Lacking this intuition, your production d

>It’s knowing how indexes work and having the intuition to create the best indexes for your queries and your data set. Lacking this intuition, your production database will eventually slow to a crawl, you’ll upgrade your hardware in vain, and when all else fails, you’ll blame both gods and men. it isn't an intuition. It is knowledge about access paths your system uses in query plans and how to manage them. "Intuition" and "use [always] indexes" - these 2 perpetrated legends is what frequently the root cause of the pitiful performance of reasonably large DB systems (ie. ones that many times larger than the RAM of the DB [cluster]). People get charmed by the "magic" of B-tree and miss the iron-platter reality of random vs stream IO. You see a DBA or DB developer expressing unconditional disgust pointing toward the red line of "Full-Table Scan" in query plan he managed to display in the GUI tool and you immediately understand what the situation at this client site is :) Again, don't get me wrong, i'n not saying that indexes shouldn't be used - that would be the same mistake as to say they should always be used. What i'm saying is that you need to know (not intuit) when and how and why to use or not to use specific access paths.