Re: Avoid detoast overhead when possible

Поиск
Список
Период
Сортировка
От Matthias van de Meent
Тема Re: Avoid detoast overhead when possible
Дата
Msg-id CAEze2Wj2TFZdddFe5dw6Wgudan3__gBHeTuHnZg9-Kv6tJ_z4g@mail.gmail.com
обсуждение исходный текст
Ответ на Avoid detoast overhead when possible  (zhihuifan1213@163.com)
Ответы Re: Avoid detoast overhead when possible  (zhihuifan1213@163.com)
Список pgsql-hackers
On Mon, 4 Dec 2023 at 07:56, <zhihuifan1213@163.com> wrote:
> 'SELECT f1(toast_col) FROM t;' will apply this code path, but nothing
> gain and nothing lost.  Applying this code path only when the toast
> datum is accessed 1+ times needs some extra run-time effort. I don't
> implement this so far, I'd like to see if I miss some obvious points.
> Any feedback is welcome.

This does add some measurable memory overhead to query execution where
the produced derivative of the large toasted field is small (e.g. 1MB
toast value -> 2x BIGINT), and when the toasted value is deep in the
query tree (e.g. 3 nested loops deep). It would also add overhead when
we write results to disk, such as spilling merge sorts, hash join
spills, or CTE materializations.

Could you find a way to reduce this memory and IO usage when the value
is not going to be used immediately? Using the toast pointer at such
points surely will be cheaper than storing the full value again and
again.

Kind regards,

Matthias van de Meent
Neon (https://neon.tech)



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tomas Vondra
Дата:
Сообщение: Re: undetected deadlock in ALTER SUBSCRIPTION ... REFRESH PUBLICATION
Следующее
От: Amit Kapila
Дата:
Сообщение: Re: undetected deadlock in ALTER SUBSCRIPTION ... REFRESH PUBLICATION