From: Justin Pryzby <pryzby@telsasoft.com>
To: Jeff Davis <pgsql@j-davis.com>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: pgsql-hackers@postgresql.org, Jacob Champion <pchampion@vmware.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Ashwin Agrawal <aagrawal@pivotal.io>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>
Cc: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Dilip Kumar <dilipbalaut@gmail.com>
Subject: Re: alter table set TABLE ACCESS METHOD
Date: Thu, 6 May 2021 15:23:05 -0500
Message-ID: <20210506202305.GQ27406@telsasoft.com> (raw)
In-Reply-To: <35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com>
References: <20210228222530.GD20769@telsasoft.com>
<YDxOhIGLPEGYINNP@paquier.xyz>
<20210308010707.GA29832@telsasoft.com>
<YEXSj7vO/ypnlIqq@paquier.xyz>
<35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: pryzby@telsasoft.com, pgsql@j-davis.com, michael@paquier.xyz, pchampion@vmware.com, hlinnaka@iki.fi, aagrawal@pivotal.io, ashu.coek88@gmail.com, andres@anarazel.de, robertmhaas@gmail.com, amit.kapila16@gmail.com, alvherre@alvh.no-ip.org, dilipbalaut@gmail.com
Subject: Re: alter table set TABLE ACCESS METHOD
In-Reply-To: <20210506202305.GQ27406@telsasoft.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox