Made post more SEO friendly

Author: Sai Wong

_posts/2015-10-16-add-columns-with-default-values-to-large-tables-in-rails-postgres.markdown renamed to _posts/2015-11-05-add-columns-with-default-values-to-large-tables-in-rails-postgres.markdown

@@ -1,6 +1,6 @@
 ---
 layout:       post
-title:        Rails Migration - How to add columns with default values to really large tables in Postgres + Rails
+title:        Adding columns with default values to really large tables in Postgres + Rails
 author:       Sai Wong
 summary:
 image:        http://res.cloudinary.com/wework/image/upload/s--GnhXQxhq--/c_scale,q_jpegmini:1,w_1000/v1445269362/engineering/shutterstock_262325693.jpg
@@ -13,16 +13,16 @@ best but for us, the fun only just started. The table in question was a fairly
 large table with lots of reads on it and in the spirit of no down time, this
 is the adventure we had.
 
-# TL:DR;
+## TL:DR;
 
 Jump straight to the [solution](#attempt-3)!
 
-# The Task
+## The Task
 - Add two columns to the notifications table
 - Both columns have default values
 - Table has 2.2 MM rows!
 
-# Attempt #1
+## Attempt #1
 ```ruby
 class AddPhoneFlagsToNotifications < ActiveRecord::Migration
   def change
@@ -32,21 +32,21 @@ class AddPhoneFlagsToNotifications < ActiveRecord::Migration
 end
 ```
 
-## Problem
+### Problem
 - Migration takes hours!
 - The notifications table is locked
 - Entire application grinds to a halt
 
-## Reason
+### Reason
 - Column creation with default values causes all rows to be touched at the same time
 - Updates are a slow operation in Postgres since it has to guarantee consistency
 - That guarantee results in whole table locking
 
-## Solution
+### Solution
 - Postgres can create null columns extremely fast! Even on a huge table!
 - We can split the work to two tasks, creating the columns and populating the default value
 
-# Attempt #2
+## Attempt #2
 
 ```ruby
 class AddPhoneFlagsToNotifications < ActiveRecord::Migration
@@ -76,24 +76,24 @@ class AddPhoneFlagsToNotifications < ActiveRecord::Migration
 end
 ```
 
-## Problem
+### Problem
 - Migration takes hours!
 - The notifications table is still locked!
 - Entire application grinds to a halt
 
-## Reason
+### Reason
 - Rails migration tasks are always wrapped in a transaction to allow for rollbacks
 - The column adds AND the row updates are in one gigantic transaction!
 - Transactions guarantee consistency
 - That guarantee results in whole table locking again!
 
-## Solution
+### Solution
 - You can disable the transaction handle in Rails migration by calling “disable_ddl_transaction!” in your migration task
 - But you have to handle transactions on your own
 - We can then run each step in its own transaction
 - Add our own error handling to rollback operation
 
-# Attempt #3
+## Attempt #3
 
 ```ruby
 class AddPhoneFlagsToNotifications < ActiveRecord::Migration
@@ -136,18 +136,18 @@ class AddPhoneFlagsToNotifications < ActiveRecord::Migration
 end
 ```
 
-## Result
+### Result
 - Migration takes hours!
 - There is no table locking
 - Application is slower due to all the writes to notifications table
 - Nothing grinds to a halt
 
-# Takeaways
+## Takeaways
 - Always be mindful of the number of rows affected in the migration
 - Be mindful of the transaction size
 - Leverage Postgres features
 
-## Possible alternate solution
+### Possible alternate solution
 - Handle NULL case in code to treat as the desired default value
   - Clean solution and quick turn around but required us to muck up the model to abstract out that case. Give that we may or may not have complete control over how that those values are extracted from the model, this may turn into lots of defensive code.
 - Add view in database to do mapping for us