Date: Thu, 6 May 2021 17:19:44 -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: <20210506221943.GS27406@telsasoft.com>
References: <20210228222530.GD20769@telsasoft.com>
 <YDxOhIGLPEGYINNP@paquier.xyz>
 <20210308010707.GA29832@telsasoft.com>
 <YEXSj7vO/ypnlIqq@paquier.xyz>
 <35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com>
 <20210506202305.GQ27406@telsasoft.com>
 <1033d6b4b5b42a014cc3f617265ae6e61cb5781b.camel@j-davis.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1033d6b4b5b42a014cc3f617265ae6e61cb5781b.camel@j-davis.com>
User-Agent: Mutt/1.9.4 (2018-02-28)
Archived-At: 
 <https://www.postgresql.org/message-id/20210506221943.GS27406%40telsasoft.com>
Precedence: bulk

On Thu, May 06, 2021 at 02:11:31PM -0700, Jeff Davis wrote:
> On Thu, 2021-05-06 at 15:23 -0500, Justin Pryzby wrote:
> > I think ALTER TABLE SET ACCESS METHOD should move all data off the
> > old AM,
> > including its toast table.
> 
> Can you explain what you mean, and why? I'm still confused.
> 
> Let's say there are 4 table AMs: A, AT, B, and BT. A's
> relation_toast_am() returns AT, and B's relation_toast_am() returns BT.
> AT or BT are invalid if A or B have relation_needs_toast_table() return
> false.
> 
> Here are the cases that I see:
> 
> If A = B, then AT = BT, and it's all a no-op.
> 
> If A != B and BT is invalid (e.g. converting heap to columnar), then A
> should detoast (and perhaps decompress, as in the case of columnar)
> whatever it gets as input and do whatever it wants. That's what
> columnar does and I don't see why ATRewriteTable needs to handle it.
> 
> If A != B and AT != BT, then B needs to detoast whatever it gets (but
> should not decompress, as that would just be wasted effort), and then
> re-toast using BT. Again, I don't see a need for ATRewriteTable to do
> anything, B can handle it.
> 
> The only case I can really see where ATRewriteTable might be helpful is
> if A != B but AT = BT. In that case, in theory, you don't need to do
> anything to the toast table, just leave it where it is. But then the
> responsibilities get a little confusing to me -- how is B supposed to
> know that it doesn't need to toast anything? Is this the problem you
> are trying to solve?

That's the optimization Michael is suggesting.

I was approaching this after having just looked at Dilip's patch (which was
originally written using pg_am to support "pluggable" compression "AM"s, but
not otherwise related to table AM).

Once a table is converted to a new AM, its tuples had better not reference the
old AM - it could be dropped.

The new table AM (B) shouldn't need to know anything about the old one (A).  It
should just process incoming tuples.  It makes more to me that ATRewriteTable
would handle this, rather than every acccess method having the same logic (at
best) or different logic (more likely).  If ATRewriteTable didn't handle this,
data would become inaccessible if an AM failed to de-toast tuples.

-- 
Justin