|
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. 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 another table. 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 invariant ?
-- john r pierce, recycling bits in santa cruz |
