Re: tableam vs. TOAST

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: tableam vs. TOAST
Дата
Msg-id 48223eba-0e73-733c-8adf-801199a65c38@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: tableam vs. TOAST  (Andres Freund <andres@anarazel.de>)
Список 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 по дате отправления:

Предыдущее
От: Kyotaro Horiguchi
Дата:
Сообщение: Re: [proposal] recovery_target "latest"
Следующее
От: Fujii Masao
Дата:
Сообщение: Re: pgbench - extend initialization phase control