Re: More guidance on ctid
| От | Bruce Momjian |
|---|---|
| Тема | Re: More guidance on ctid |
| Дата | |
| Msg-id | aUwKSGHaZAd5_xKl@momjian.us обсуждение исходный текст |
| Ответ на | Re: More guidance on ctid (Bernice Southey <bernice.southey@gmail.com>) |
| Ответы |
Re: More guidance on ctid
Re: More guidance on ctid |
| Список | pgsql-docs |
On Wed, Dec 24, 2025 at 03:26:23PM +0000, Bernice Southey wrote: > > Okay, let's give it another 12 hours and I will apply it tomorrow, > > thanks. > I had a new thought. Perhaps the root problem is trying to put too > many things into one example. We can use the two examples to show > different things. > > I've kept batching - with skip lock, limit and ctid - in DELETE. Other > than switching out skip lock for order by, this is much the same as > currently, but with all the existing update explanatory text moved > here. Skip lock makes ctid safe, and this is a good use of it. > > I've used UPDATE to show how to prevent deadlocks with order by, for > update, and an immutable key. This meant explaining why an immutable > key matters, conveniently ruling out ctid without even mentioning it. > > I think this now covers how to order by and limit with update and > delete, how and why to batch, how to safely avoid deadlocks, how to > use for update (with and without skip lock) and when and when not to > use ctid. > > But if you don't like this approach, I'm still happy if you go with > your patch. I expect my patch needs quite a bit more work, even if you > do like it. We could go in the direction you suggested, but it seems out-of-place in the UPDATE/DELETE docs since it gets into a lot of details. Maybe in the locking chapter? -- Bruce Momjian <bruce@momjian.us> https://momjian.us EDB https://enterprisedb.com Do not let urgent matters crowd out time for investment in the future.
В списке pgsql-docs по дате отправления: