3 ms·
I pick correct semantics NOW and fix performance issues at your leisure. upsert has been an embarrassment for Postgres for far too long now. Particularly obnox
by spitfire 12y ago
I pick correct semantics NOW and fix performance issues at your leisure.
upsert has been an embarrassment for Postgres for far too long now. Particularly obnoxious was the "upsert is hard! Roll your own" stance taken.
- jeffdavis 12y agoA completely reasonable stance. However, it's not so much a performance question as one of concurrency. The easiest way to get the right semantics is by locking the entire destination table against concurrent writes. Maybe that's fine for a lot of users. But it has caused some hesitation, because other users might be disappointed. It would be fair to say "just do it" though.
- audreyt 12y agoPart of the motivation behind PgREST is to get a reusable and generic enough upsert implementation as a stored procedure; see https://github.com/pgrest/pgrest/blob/master/test/upsert.ls https://github.com/pgrest/pgrest/blob/master/test/upsert.ls for details.