Re: tableam vs. TOAST - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: tableam vs. TOAST
Date
Msg-id 48223eba-0e73-733c-8adf-801199a65c38@2ndquadrant.com
Whole thread Raw
In response to Re: tableam vs. TOAST  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
On 2019-11-06 18:00, Andres Freund wrote:
> I'd like an AM to have the *option* of implementing something better, or
> at least go in the direction of making that possible.

I don't think the presented design prevents that.  An AM can just return 
false from relation_needs_toast_table in all cases and implement 
something internally.

> It seems perfectly possible to have a helper function implementing the
> current logic that you just can call with the fixed chunk size as an
> additional parameter. Which'd basically mean there's no meaningful
> difference in complexity compared to providing the chunk size as an
> external AM property. In one case you have a callback that just calls a
> helper function with one parameter, in the other you fill in a member of
> the struct.

I can see a "moral" concern about having TOAST be part of the table AM 
API.  It should be an implementation concern of the AM.  How much more 
work would it be to refactor TOAST into a separate API that an AM 
implementation could use or not?  How much more complicated would the 
result be?  I guess you would like to at least have it explored.

-- 
Peter Eisentraut              http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services



pgsql-hackers by date:

Previous
From: Kyotaro Horiguchi
Date:
Subject: Re: [proposal] recovery_target "latest"
Next
From: Fujii Masao
Date:
Subject: Re: pgbench - extend initialization phase control