clean bulk upsert optimization

[pallavi2209]

No description provided.

[coveralls]

Coverage increased (+0.6%) to 84.122% when pulling 3bbd18c on clean-bulk-upsert into 517b715 on master.

[iamigo]

Do we need to remove this? Seems like a good thing to have around regardless, no?

[pallavi2209]

I think it would hurt us to have extra indexes.
See: http://stackoverflow.com/questions/20707182/disadvantages-of-creating-multiple-indexes-in-a-postgresql-table

indexes have a performance penalty when it comes to INSERTing new rows, DELETEing old ones or UPDATEing existing values of the indexed column, as now the DML statement need not only modify the table's data, but the index's one too

[iamigo]

OK

(... although I could argue that with our usage pattern there wouldn't actually be a penalty for indexing name because samples rarely get created or deleted, and when they're updated, the name is typically not updated).

[pallavi2209]

Hmm.. I see your point. I can add the index back in if @shriramshankar has no issues.

[shriramshankar]

https://devcenter.heroku.com/articles/expensive-queries. Looks like unused indexes could also be a cause of slow DML operations.

[iamigo]

ok get rid of it

[coveralls]

Coverage increased (+0.5%) to 84.034% when pulling d9e479b on clean-bulk-upsert into 893f46a on master.

[coveralls]

Coverage increased (+0.5%) to 83.959% when pulling ffb2958 on clean-bulk-upsert into 1982d90 on master.