Re: alter table set TABLE ACCESS METHOD

On Mon, Mar 08, 2021 at 04:30:23PM +0900, Michael Paquier wrote:
> This toast issue is a kind of interesting one, and it seems rather
> right to rely on toast_build_flattened_tuple() to decompress things if
> both table AMs support toast with the internals of toast knowing what
> kind of compression has been applied to the stored tuple, rather than
> have the table AM try to extra a toast tuple by itself. I wonder
> whether we should have a table AM API to know what kind of compression
> is supported for a given table AMs at hand, because there is no need
> to flatten things if both the origin and the target match their
> compression algos, which would be on HEAD to make sure that both the
> origin and table AMs have toast (relation_toast_am). Your patch,
> here, would flatten each tuples as long as the table AMs don't
> match. That can be made cheaper in some cases.

I actually have an idea for this one, able to test the decompression
-> insert path when rewriting a relation with a new AM: we could add a
dummy_table_am in src/test/modules/. By design, this table AM acts as
a blackhole, eating any data we insert into it but print into the logs
the data candidate for INSERT. When doing a heap -> dummy_table_am
rewrite, the logs would provide coverage with the data from the origin
toast table. The opposite operation does not really matter, though it
could be tested. In one of my trees, I have something already close
to that:
https://github.com/michaelpq/pg_plugins/tree/master/blackhole_am/
--
Michael