Re: alter table set TABLE ACCESS METHOD
Justin Pryzby <pryzby@telsasoft.com>
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>
Date: 2021-05-06T22:19:44Z
Lists: pgsql-hackers
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
Commits
-
Allow specifying an access method for partitioned tables
- 374c7a229042 17.0 landed
-
Fix regression test output of sepgsql
- 1e3445237b86 15.0 landed
-
Add call to object access hook at the end of table rewrite in ALTER TABLE
- 7b565843a944 15.0 landed
-
Fix typo in tab-complete.c
- 15c6ede04577 15.0 landed
-
Add support for SET ACCESS METHOD in ALTER TABLE
- b0483263dda0 15.0 landed
-
tableam: introduce table AM infrastructure.
- 8586bf7ed888 12.0 cited