pg.ddx.io pgsql-hackers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
From: Jeff Davis <pgsql@j-davis.com>
To: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
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, 06 May 2021 13:10:53 -0700
Message-ID: <35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com> (raw)
In-Reply-To: <YEXSj7vO/ypnlIqq@paquier.xyz>
References: <20210228222530.GD20769@telsasoft.com>
<YDxOhIGLPEGYINNP@paquier.xyz>
<20210308010707.GA29832@telsasoft.com>
<YEXSj7vO/ypnlIqq@paquier.xyz>
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/columna...
view thread (41+ messages) latest in thread
Message-ID: <35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com> Permalink: ../35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com/ Also on: postgresql.org/message-id/35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.com ·
reply
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: pgsql@j-davis.com, michael@paquier.xyz, pryzby@telsasoft.com, 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: <35333ea26e52252174515e14671a9fbc1c20c8fa.camel@j-davis.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