On 9/16/2016 3:46 AM, Chris Withers wrote:
Yeah, it's a temporal table, so "updates" involve modifying the period
column for a row to set its end ts, and then inserting a new row with
a start ts running on from that.
when you do updates, are you changing any of the indexed fields, or
just "value" ?
thats expensive, as it has to reindex that row. and range indexes are
more expensive than timestamp indexes
modifiyng the primary key is kind of a violation of one of the basic
rules of relational databases as it means the row can't be referenced by
I expect the expensive one is the constraint that ensures no periods
overlap for the given key. I'm not sure how that can be done short of
a full scan for each update/insert. it might actually perform better
if you write the index with the key first as presumably the key is
john r pierce, recycling bits in santa cruz