| From: | Corey Huinker <corey(dot)huinker(at)gmail(dot)com> |
|---|---|
| To: | Joel Jacobson <joel(at)compiler(dot)org> |
| Cc: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, vignesh C <vignesh21(at)gmail(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Marko Tiikkaja <marko(at)joh(dot)to> |
| Subject: | Re: Document efficient self-joins / UPDATE LIMIT techniques. |
| Date: | 2024-02-15 18:41:57 |
| Message-ID: | CADkLM=dswiXCCYjC+Q=XCOHjQjF8gWr-0Q_Ljkwqive=0MeKdQ@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2024-02-15 18:59:11 | Re: RFC: Logging plan of the running query |
| Previous Message | Alexander Lakhin | 2024-02-15 18:00:00 | Re: partitioning and identity column |