From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Prabhat Sahu <prabhat(dot)sahu(at)enterprisedb(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: tableam vs. TOAST |
Date: | 2019-11-06 09:01:40 |
Message-ID: | dfa64612-8ba4-7cd7-d411-9963c2d7482c@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-10-04 20:32, Robert Haas wrote:
> Here's the last patch back, rebased over that renaming. Although I
> think that Andres (and Tom) are probably right that there's room for
> improvement here, I currently don't see a way around the issues I
> wrote about inhttp://postgr.es/m/CA+Tgmoa0zFcaCpOJCsSpOLLGpzTVfSyvcVB-USS8YoKzMO51Yw@mail.gmail.com
> -- so not quite sure where to go next. Hopefully Andres or someone
> else will give me a quick whack with the cluebat if I'm missing
> something obvious.
This patch seems sound as far as the API restructuring goes.
If I may summarize the remaining discussion: This patch adds a field
toast_max_chunk_size to TableAmRoutine, to take the place of the
hardcoded TOAST_MAX_CHUNK_SIZE. The heapam_methods implementation then
sets this to TOAST_MAX_CHUNK_SIZE, thus preserving existing behavior.
Other table AMs can set this to some other value that they find
suitable. Currently, TOAST_MAX_CHUNK_SIZE is computed based on
heap-specific values and assumptions, so it's likely that other AMs
won't want to use that value. (Side note: Maybe rename
TOAST_MAX_CHUNK_SIZE then.) The concern was raised that while
TOAST_MAX_CHUNK_SIZE is stored in pg_control, values chosen by other
table AMs won't be, and so they won't have any safe-guards against
starting a server with incompatible disk layout. Then, various ways to
detect or check the TOAST chunk size at run time were discussed, but
none seemed satisfactory.
I think AMs are probably going to need a general mechanism to store
pg_control-like data somewhere. There are going to be chunk sizes,
block sizes, segment sizes, and so on. This one is just a particular
case of that.
This particular patch doesn't need to be held up by that, though.
Providing that mechanism can be a separate subproject of pluggable storage.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Skjalg A. Skagen | 2019-11-06 09:30:34 | Re: PostgreSQL 12 installation fails because locale name contained non-english characters |
Previous Message | Kyotaro Horiguchi | 2019-11-06 08:36:09 | Re: Should we make scary sounding, but actually routine, errors less scary? |