DBAs and Developers, Do you suffer from Performance Dysfunction (PD)?
DBAs and developers, do you suffer from PD? PD, performance dysfunction, is not a topic that many like to discuss. A few people do but they mostly hang out together at conferences and talk about the size of their tuples. For the rest of us, PD is an evil, evil thing.
There are as many types of PD as there are causes. Today I want to talk about a particularly insidious type referred to as PO or Premature Optimization. PO can strike at any time, any where. It’s nothing to be embarrassed about but it is something to fix. If you don’t nip PO in the bud you might end up with POCA (piece of crap application) syndrome.
What are the symptoms of PO?
- Denormalizing data models before the model is complete – It makes sense at times to denormalize data: star schemas, reporting/read mostly instances, etc. Normalize first and only if required for design purposes, denormalize only as much as the design calls for. Save the performance denormalizations for an actual, measured benefit (as in measure before and after to see if it did anything).
- Reflexive indexing – Someone says “It’s slow”, you create an index. That’s reflexive indexing. It’s a bad, bad thing.
- When someone says “It’s slow”, you assume you know what they mean.
- You don’t know how slow “it” is because you have never measured it.
- You don’t know has fast “it” should be.
- You want to protect the system by eliminating nasty joins (also referred to joinaphobia or relational gonorrhea)
- You want to loop instead of using cursors (because your loops are faster than a 1,000,000 man hour, developed and tested, relational database)
- There are more symptoms than can be listed here
How can you cure PO?
- a warm bath, a bottle of champagne and a disk of Barry White won’t take care of PO so don’t try
- Model your data, not your performance
- Index intelligently, not randomly
- Define “it’s”
- Define “slow”
- Set goals, how fast is fast enough?
- Set limits, when do you stop making it faster?
- Denormalize when needed, not when thought about. Denormalizing for performance is not a panacea and many times doesn’t help you at all (if you include the extra maintenance it causes, I would say most times).
- Databases do joins pretty nicely now a days. MySQL and Postgres still have issues with complex joins but even they are getting better all the time.
- Use SQL first, code second
PO can not only lead to POCA but also to Performance Anxiety and Perfapism (the need to make everything go faster). If you suffer from PO for more than 4 applications in a row, you may have Perfapism. Perfapism can be uncomfortable, especially for those working around you. The automatic door really only needs to open so fast.
As much as I hate to admit it, I have suffered with POCA syndrome. I have been POCA free for over a decade now. Don’t let POCA bite you in the ass. Stamp out PO now! With a little more thought and a little less knee jerking, you too can be PO free. Get out there and get it up! It, being your performance of course.
You can follow any responses to this entry through the RSS 2.0 feed. Both comments and pings are currently closed.