Horton

Re: tableam vs. TOAST

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Prabhat Sahu <prabhat.sahu@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-09-05T20:07:20Z
Lists: pgsql-hackers 
On 2019-09-05 15:27:28 -0400, Robert Haas wrote:
> On Thu, Sep 5, 2019 at 3:10 PM Andres Freund <andres@anarazel.de> wrote:
> > On 2019-09-05 13:42:40 -0400, Robert Haas wrote:
> > > Done, thanks. Here's the rest again with the additional rename added
> > > to 0003 (formerly 0004). I think it's probably OK to go ahead with
> > > that stuff, too, but I'll wait a bit to see if anyone wants to raise
> > > more objections.
> >
> > Well, I still dislike making the toast chunk size configurable in a
> > halfhearted manner.
> 
> So, I'd be willing to look into that some more.  But how about if I
> commit the next patch in the series first?  I think this comment is
> really about the second patch in the series, "Allow TOAST tables to be
> implemented using table AMs other than heap," and it's fair to point
> out that, since that patch extends table AM, we're somewhat committed
> to it once we put it in.  But "Create an API for inserting and
> deleting rows in TOAST tables." is just refactoring, and I don't see
> what we gain from waiting to commit that part.

Yea, makes sense to me.

Commits

  1. tableam: New callback relation_fetch_toast_slice.

  2. tableam: Allow choice of toast AM.

  3. Move heap-specific detoasting logic into a separate function.

  4. Code cleanup for toast_fetch_datum and toast_fetch_datum_slice.

  5. Rename some toasting functions based on whether they are heap-specific.

  6. Create an API for inserting and deleting rows in TOAST tables.

  7. Split tuptoaster.c into three separate files.

  8. tableam: Move heap-specific logic from needs_toast_table below tableam.