Re: More guidance on ctid

From: Bernice Southey <bernice(dot)southey(at)gmail(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: More guidance on ctid
Date: 2025-12-24 15:26:23
Message-ID: CAEDh4nyStja3R4X6qW_zpKz2w8EPUTsHQ8S0k9_saPA7BT+quw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

Attachment Content-Type Size
v3-rework-update-and-delete-self-join-examples.patch text/x-patch 6.8 KB

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Bruce Momjian 2025-12-24 15:44:08 Re: More guidance on ctid
Previous Message Bruce Momjian 2025-12-23 23:23:07 Re: More guidance on ctid