Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains - Mailing list pgsql-general

From John R Pierce
Subject Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains
Date
Msg-id af4f226a-84e5-85f3-28a2-f703ac53b5a6@hogranch.com
Whole thread Raw
In response to Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains  (Chris Withers <chris@simplistix.co.uk>)
Responses Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains  (Chris Withers <chris@simplistix.co.uk>)
Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains  (Chris Withers <chris@withers.org>)
List pgsql-general
On 9/16/2016 3:46 AM, Chris Withers wrote:

when you do updates, are you changing any of the indexed fields, or
just "value" ?
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

pgsql-general by date:

Previous
From: Chris Withers
Date:
Subject: Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains
Next
From: Chris Withers
Date:
Subject: Re: performance problems with bulk inserts/updates on tsrange with gist-based exclude constrains