MSM

Good list here. A few things I would add about execution plans specifically.

1. SET STATISTICS IO ON. This is much more useful than setting time on imo. This will give you physical / logical reads per table as well as how specifically they were fetched. Usually I don't care if the query took 11 seconds, I want to know what took those 11 seconds.

2. The % numbers that everyone relies on when skimming execution plans are total BS. No one seems to realize this, but the percentage values are based off of the estimated query plan even when you're running the actual execution plan. Use the plan to determine which operators were chosen, disregard the % values. To get the true amount of work done, look at stats IO above. If your underlying issues is missing or stale stats for example, that incorrect data will pass through to your execution plan and that plan will lie to you.

3. Try to determine why a plan is getting generated. Don't just keep trying wacky code changes until you can get the correct plan (once..), find out what the optimizer is seeing and why it's doing what it's doing. You may know what operation is best in the current moment ("this was much faster as a nested loop") but instead of using a join hint, force the optimizer's hand by correcting whatever underlying issue is making it think that the merge/hash is a better route. This will save future-you hours of head-bashing when, inevitably, that join hint that was added three years ago causes a big production issue.

Mayer had absolutely nothing to do with Alibaba or Yahoo Japan though. What she is directly in control of has been hemorrhaging money.

I think instead of trying to shoehorn the "AND" that he discusses in the article into a case statement you'd just look for each category to see if there has been a non expressed delivered package.

  SELECT 
      category, 
      ISNULL(NonExpress.NonExpress, 0) AS ever_been_non_express_delivered
  FROM @orders O
  OUTER APPLY (
     SELECT TOP 1 1 as [NonExpress]
     FROM @Orders O2
     WHERE O2.Category = O.Category
        AND express_delivered = 0
  ) NonExpress
  GROUP BY category

Edit: Changed the logic up, the original code's field was contradicting my logic.

That's actually pretty surprising to me, I have only visited Colorado a few times but I have always been very (pleasantly) surprised by the amount of sunshine.

A quick look on Wikipedia says Denver has sunshine 70% of the time totaling ~3,100 hours a year. I'm from MI where we see sun about once a week so I'm out of touch, but that seems like it should be more than enough to recoup costs.

Is the amount of sunshine in Denver significantly different from where you're at, or is there something else I'm missing?

I had/have an algorithm that I use for MLB games. The stats are relatively easy to find and past that it's just trying to figure out what things "matter". I had a lot of fun day dreaming about which things are important to factor in. Some parks are hitters parks, some pitchers walk batters more often, most batters have a better average depending on the handedness of the pitcher, etc. There are thousands of things you can factor in.

If I'm being honest, it didn't make a whole lot of money before I shelved it myself. The most important factor is that the lineups are rarely submitted early enough for me to bet on a full day. Usually I found myself being able to only play the late games, which is typically 4-6 total teams. It really limits the creativity of the lineups.

In the future I'd like to try it with some other sports (NBA is a big one, because the lineup issue shouldn't be as big of a factor, same with hockey). But I don't expect to make millions, it's just a programming problem that's a ton of fun to solve for.

Most databases have ways for you to specify the exact plan you want used already. Since you mentioned SQL Server, you can force join order, force index usage, force the type of join used (loop, merge, hash), etc.

There are terrible drawbacks using any of those techniques (data changes, indexes being modified / dropped, etc) which is why, imo, they should very rarely be used. However, 'allowing direct specification of the query plan' is already implemented in that respect.

The better way to address the problem of different parameters causing performance issues is forcing recompiles which will solve the problem 95% of the time.

TWTR right now has a operating margin of -26%. So they spent ~1.3B to get that 1.0B in revenue.

If I were to make a bunch of goods for $130/each, and then sell them for $100/each but managed to sell 10M of those goods should I be valued as a billion dollar company?

I imagine that has to play a HUGE part in how he's able to stay out of work. If it's exactly "a few hundred a week" that still adds up to ~15,600 a year. I know the cost of living is pretty high over there but that's a really healthy chunk of change to be able to count on.

"Tanking"?

That didn't even cause the lowest trading price of the past 24 hours.

I have heard the opposite from many studies as well. You linked a post that spawned many, many rebuttals by various organizations.

http://economix.blogs.nytimes.com/2011/07/01/richer-people-w...

http://freakonomics.com/2011/06/10/the-rich-vs-poor-debate-a...

SQL Server has all this information saved (I'm not paid by Microsoft, I swear). I would suspect something is available for other engines as well.

For example, I can easily grab (what it thinks are) the top 10 most impactful missing indexes and create them. The big issue is that, well, they can be really dumb when looking at a macro level. Do I often query a 10 column table for 8 of the columns? It will likely recommend I index those 8 columns. In a vacuum that might be a great index for this specific query, but now I'm basically maintaining two copies of the full table.

To be able to weigh these pros and cons would be a really nice feat, then DBAs will have to abandon the "It Depends" mantra!

There shouldn't be a situation where reading the data + creating the index would be less intensive than just reading the data.

This is from the SQL server perspective so I apologize if all this doesn't translate 100%. Let's say the column you're filtering on is currently not in any index. That field then needs to be pulled out of the clustered index's leaf pages. Since it's unsorted, we'd need to read the entire table- a full scan.

To build the temporary index we'd also need to read in all of the data, so the same amount of work from that perspective, but then we'd have to sort it all, which is very intensive.

If there's a situation where we're doing something analogous to a inner loop join in SQL Server, but it's doing full scans for each iteration, that's a problem with the query optimizer.

SQL gives you all of the tools you need to hang yourself if you're bent on it. FORCE ORDER will force joins to happen in the order specified, index / join hints will force the optimizer to do things the way you'd like.

The reason these things aren't seen often is because they are a terrible code smell. An index that works today may not be the best bet tomorrow. The beauty of the optimizer is it takes the (estimated) statistics available to it on execution to build a performant plan.

The author is basically taking a huge no-no (forcing specific index use / order of operations) and somehow trying to sell that as a positive.

I've had a few conversations with friends about which sport I'd choose to play if I could be a professional in any sport. I think baseball would be at the bottom of my list.

You have to go to the ballpark nearly every single day for almost 8 months. I'm from Detroit and I'm looking at the Tiger's schedule right now. In September they have TWO days in the entire month without a game. By that time they will also be playing doubleheaders or make up games because of weather. In May they go 21 consecutive days with a game. Even if it's not as physically demanding as hockey or american football, that's exhausting. Imagine having to go to the office that much.

On top of that you're playing until nearly November if you're in the World Series and then spring training starts in Feb (it's already started). There's nearly no offseason.

I definitely agree he should factor in costs that he wouldn't have been paying before. I thought his including his entire car was a little disingenuous, that's all.

Everyone needs a car. If my car breaks down I would likely have to take a sick day to get it to the shop. No one factors that into their pay. I need to wear pants when I go into the office, do I get to allocate pants into my wage?

A car is something almost everyone needs. He's going to end up factoring it into his hourly wage and then getting a car for free.

He isn't getting paid well, I agree with him there. However, factoring your car payment and car insurance into your hourly wage just because you happen to work from your car is kind of silly. If I work from home do I factor my house payment into my hourly wage?

but not for any combination that doesn't have B leading.

If you're always going to query those fields in that order, that's a perfect way to do things. If you'll be querying it a couple different ways then you're way better off with three separate one column indexes assuming the RDBMS can make use of index intersection.

My understanding is that the only reason these jobs aren't automated already is because labor is cheaper. Unfortunately I think the alternative to a terrible job like working for Foxconn is no job at all for a lot of folks.

My eyes went to this immediately:

"..outdated softwae at America's largest home improvement retailer"

Article lambasting Microsoft for not reviewing their product enough before it gets sent out, sends out a product that clearly wasn't reviewed enough.

Was broken when I checked earlier, seems to be fixed.

They mentioned ORM so they don't need a DBA!

Jokes aside, I still think profiling is a great idea here. Even if you're not responsible for writing the database portion, it's important to see how much time those calls are taking.

And sitting in front of a computer for an extra 16 hours a week learning to program at the age of 12 instead of having normal social interactions is supposed to enable her to have "healthier relationships with other people"?

> blowing off your obligations

She is 12 years old. Are you people mad? She has very few obligations and that's a good thing. Let her have some fun before she needs to start being an adult.

If I make a mistake at doing my taxes and accidentally pay $1,000 less than I should is that the same as knowingly gaming the system so that I have to pay $1,000 less?

Is one of those considered stealing?

> Publishing identifying information on someone hugely influential is very much ethical.

How can you even say that? It's easy to say that if (assumption) you haven't done anything "hugely influential", but I think the feeling would be different if this article was about you.

It's plain disrespectful. The guy obviously wants to be left alone or he wouldn't have stopped emailing, stopped answering the phone or called police when the reporter showed up.

I have to second the cheap. I can either make a full pot of coffee for ~$2-3/pot or I can make a single cup for ~$.75/cup. I understand it might not be the best bang for my buck but I'm only interested in drinking one cup so it's pretty cost effective in my eyes.

I belive it should be 'Through'

Alright, so I managed to dig up the raw data by county.[1]

I think I crunched the numbers correctly, but I wouldn't bet money on it being 100%. I just took the winning % per county and took a weighted average across the nation. I believe that should give me the desired results. The result set I used was purely presidential votes between only Obama and Romney which gave me some weird stuff like Harris, TX having a majority vote of 49.4% (also the third highest voting county, which hurt the average). Anyway, it was a fun excercise and it appears that pandora is estimated to be 25-30% more accurate than guessing on county/zip alone.

I ended up seeing 61.29% as the average "majority" in each county.

[1] http://www.theguardian.com/news/datablog/2012/nov/07/us-2012...

Thanks! Managed to find a raw data source, added a reply to myself.

> " Mr. Krawczyk said he believes Pandora's predictions are between 75% and 80% accurate"

This doesn't really seem noteworthy at all. I would be interested to know on a national level, percentage-wise what the average majority of each county votes.

I don't know how to word that better unfortunately, so here's an example: If we have three counties with equal population and one votes 81% republican, another 71% republican and the third 88% democrat, I would be able to determine your voting preferences by county alone with ~80% correctness. I know some states are swing states, but I think that a lot of those counties are still strong in one direction.

Anyone know where this data might exist just for kicks?