Re: alter table set TABLE ACCESS METHOD

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>, pgsql-hackers@postgresql.org, Jacob Champion <pchampion@vmware.com>, Heikki Linnakangas <hlinnaka@iki.fi>, Ashwin Agrawal <aagrawal@pivotal.io>, Ashutosh Sharma <ashu.coek88@gmail.com>, Andres Freund <andres@anarazel.de>, Robert Haas <robertmhaas@gmail.com>, Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, Dilip Kumar <dilipbalaut@gmail.com>
Date: 2021-06-04T05:58:13Z
Lists: 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

Commits

  1. Allow specifying an access method for partitioned tables

  2. Fix regression test output of sepgsql

  3. Add call to object access hook at the end of table rewrite in ALTER TABLE

  4. Fix typo in tab-complete.c

  5. Add support for SET ACCESS METHOD in ALTER TABLE

  6. tableam: introduce table AM infrastructure.