| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Greg Burd <greg(at)burd(dot)me> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, John Naylor <johncnaylorls(at)gmail(dot)com> |
| Subject: | Re: Refactor how we form HeapTuples for CatalogTuple(Insert|Update) |
| Date: | 2025-12-04 05:50:09 |
| Message-ID: | aTEhEQ8hbJHV9cJ8@paquier.xyz |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Dec 03, 2025 at 09:11:03AM -0500, Greg Burd wrote:
> On Dec 2 2025, at 11:16 pm, Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> I've looked in the email archives a bit and didn't come up with much
> related to catalog upgrades. I don't know if there is much on the
> record information on this idea, but from what I've been told the idea
> of decoupling heap from catalogs with the goal of getting closer to
> making online upgrades possible has been referenced a few times in
> hallway tracks at various conferences.
John Naylor has been looking at this problem at some point, if I
recall correctly. Adding him in CC here for comments and opinions, or
perhaps I am just wrong in assuming that he has looked at this area.
> I'll see what I can do to extract this piece into a separate patch.
Thanks. I suspect that it would help with the clarity of the changes.
At least I am getting the same impression after reading v2, which is
close enough to v1 except for the various renames.
> There are two major paths into heap_update(), one from
> heapam_tuple_update() and one from simple_heap_update(). The first is
> from the executor side via the table AM API and my other thread [6] that
> you referenced is trying to address that. This thread is focused on the
> catalog updates that flow into simple_heap_update(). Really that
> function should be renamed to catalog_heap_update() as that's the only
> purpose AFAICT.
You have a point based on how things are presented in this patch set,
where there is only one caller of simple_heap_update(), versus two on
HEAD.
> Does that connect the dots a bit more clearly?
>
> * 0003 Refactor how we form HeapTuples for CatalogTuple(Insert|Update)
>
> This commit is borrowed from the other thread to demonstrate how these
> changes impact heap updates. Thanks for your consideration, I
> appreciate your time.
Now I see the connection, thanks to 0003 where simple_heap_update()
gains its Bitmapset that tracks the set of updated tuples, for the
business that happens in CatalogTupleUpdate(). All that is going to
need a careful lookup.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2025-12-04 05:54:09 | Re: index prefetching |
| Previous Message | Tom Lane | 2025-12-04 05:32:47 | Re: Something in our JIT code is screwing up PG_PRINTF_ATTRIBUTE |