Re: Document efficient self-joins / UPDATE LIMIT techniques.
Corey Huinker <corey.huinker@gmail.com>
From: Corey Huinker <corey.huinker@gmail.com>
To: Joel Jacobson <joel@compiler.org>
Cc: Laurenz Albe <laurenz.albe@cybertec.at>, vignesh C <vignesh21@gmail.com>, pgsql-hackers@lists.postgresql.org, Marko Tiikkaja <marko@joh.to>
Date: 2024-02-15T18:41:57Z
Lists: pgsql-hackers
> > > As for whether it's commonplace, when I was a consultant I had a number > > of customers that I had who bemoaned how large updates caused big > > replica lag, basically punishing access to records they did care about > > in order to properly archive or backfill records they don't care about. > > I used the technique a lot, putting the update/delete in a loop, and > > often running multiple copies of the same script at times when I/O > > contention was low, but if load levels rose it was trivial to just kill > > a few of the scripts until things calmed down. > > I've also used the technique quite a lot, but only using the PK, > didn't know about the ctid trick, so many thanks for documenting it. tid-scans only became a thing a few versions ago (12?). Prior to that, PK was the only way to go.
Commits
-
Doc: show how to get the equivalent of LIMIT for UPDATE/DELETE.
- 2daeba6a4e49 17.0 landed