Search Postgresql Archives

Table Design for Many Updates

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux