Well, then, in a sense you've answered your own question, right? You've decided to cripple the optimizer in the "select" case in order to speed up the "insert/update" case.
Perfectly OK but it's not really a true measure of the efficiency of one form of query over another because you're not optimizing your datamodel for that query (the select) but rather for dml statements.
It is a great example of the trade-offs involved when you do traffic analysis, though! In this case you know that there are many "insert/update" dml statements and rather few "select"s.
What you may not know is that PG is relatively poor, performance-wise, at "update" dml statements. So your dropping of the index is helping to mask that.
(this isn't a PG knock, PG's extremely good at other things and insert/update performance is near top of the list for future banging in PG 7.3)
