Re: More guidance on ctid
| От | Bernice Southey |
|---|---|
| Тема | Re: More guidance on ctid |
| Дата | |
| Msg-id | CAEDh4nyStja3R4X6qW_zpKz2w8EPUTsHQ8S0k9_saPA7BT+quw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: More guidance on ctid (Bruce Momjian <bruce@momjian.us>) |
| Ответы |
Re: More guidance on ctid
|
| Список | pgsql-docs |
> 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. Thanks, Bernice
Вложения
В списке pgsql-docs по дате отправления: