Re: alter table set TABLE ACCESS METHOD - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: alter table set TABLE ACCESS METHOD
Date
Msg-id YLnA9eFuayKxCr2q@paquier.xyz
Whole thread Raw
In response to Re: alter table set TABLE ACCESS METHOD  (Jeff Davis <pgsql@j-davis.com>)
Responses Re: alter table set TABLE ACCESS METHOD  (Jeff Davis <pgsql@j-davis.com>)
List pgsql-hackers
On Thu, Jun 03, 2021 at 02:36:15PM -0700, Jeff Davis wrote:
> Do we have general agreement on this point? Did I miss another purpose
> of detoasting in tablecmds.c, or can we just remove that part of the
> patch?

Catching up with this thread..  So, what you are suggesting here is
that we have no need to let ATRewriteTable() do anything about the
detoasting, and just push down the responsability of detoasting the
tuple, if necessary, down to the AM layer where the tuple insertion is
handled, right?

In short, a table AMs would receive on a rewrite with ALTER TABLE
tuples which may be toasted, still table_insert_tuple() should be able
to handle both:
- the case where this tuple was already toasted.
- the case where this tuple has been already detoasted.

You are right that this would be more consistent with what heap does
with heap_prepare_insert().
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Move pg_attribute.attcompression to earlier in struct for reduced size?
Next
From: Michael Paquier
Date:
Subject: Re: Teaching users how they can get the most out of HOT in Postgres 14