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().
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
Or does the problem apply to all of these cases?
And if tableam1 can't handle some case, why can't it just detoast the
data itself? Shouldn't that be able to decompress anything?
For example, in columnar[1], we just always detoast/decompress because
we want to compress it ourselves (along with other values from the same
column), and we never have a separate toast table. Is that code
incorrect, or will it break in v14?
Regards,
Jeff Davis
https://github.com/citusdata/citus/blob/6b1904d37a18e2975b46f0955076f84c8a387cc6/src/backend/columnar/columnar_tableam.c#L1433