Table Design for Many Updates

I have a multi-tenant database that I'm migrating from SQL Server to
PostgreSQL 9.6.1. I read the recent articles about the potential write
amplification issue in Postgres. I have one particular table that has 14
columns, a primary key, five foreign keys, and eight indexes. We have a
little over a thousand devices (this number will increase over time) on the
Internet that will insert a row into this table and then proceed to update
two columns in that row about once a minute for the next two hours. The two
columns are NOT NULL and are not FK or indexed columns. I've thought about
moving them to a one-to-one related table. Any thoughts on if this is a
wise move or if I'm making a mountain out of a mole hill? It looks like
this scenario would be covered by the Heap-Only-Tuple update but with over a
hundred updates to the same row and over a thousand different rows being
updated at a time, will I reap the benefits?

Thanks,

Craig