Date: Thu, 6 May 2021 15:23:05 -0500
From: Justin Pryzby <pryzby@telsasoft.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Michael Paquier <michael@paquier.xyz>, 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>
Subject: Re: alter table set TABLE ACCESS METHOD
Message-ID: <20210506202305.GQ27406@telsasoft.com>
References: <20210228222530.GD20769@telsasoft.com>
 <YDxOhIGLPEGYINNP@paquier.xyz>
 <20210308010707.GA29832@telsasoft.com>
 <YEXSj7vO/ypnlIqq@paquier.xyz>
 <35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210506202305.GQ27406%40telsasoft.com>
Precedence: bulk

On Thu, May 06, 2021 at 01:10:53PM -0700, Jeff Davis wrote:
> On Mon, 2021-03-08 at 16:30 +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 am confused by this. The toast-related table AM API functions are:
> relation_needs_toast_table(), relation_toast_am(), and
> relation_fetch_toast_slice().

I wrote this shortly after looking at one of Dilip's LZ4 patches.

At one point in February/March, pg_attribute.attcompression defined the
compression used by *all* tuples in the table, rather than the compression used
for new tuples, and ALTER SET COMPRESSION would rewrite the table with the new
compression (rather than being only a catalog update).


> What cases are we trying to solve here?
> 
> 1. target of conversion is tableam1 main table, heap toast table
> 2. target of conversion is tableam1 main table, no toast table
> 3. target of conversion is tableam1 main table, tableam1 toast table
> 4. target of conversion is tableam1 main table, tableam2 toast table

I think ALTER TABLE SET ACCESS METHOD should move all data off the old AM,
including its toast table.  The optimization Michael suggests is when the new
AM and old AM use the same toast AM, then the data doesn't need to be
de/re/toasted.

Thanks for looking.

-- 
Justin