Re: Avoid detoast overhead when possible - Mailing list pgsql-hackers

From Matthias van de Meent
Subject Re: Avoid detoast overhead when possible
Date
Msg-id CAEze2Wj2TFZdddFe5dw6Wgudan3__gBHeTuHnZg9-Kv6tJ_z4g@mail.gmail.com
Whole thread Raw
In response to Avoid detoast overhead when possible  (zhihuifan1213@163.com)
Responses Re: Avoid detoast overhead when possible
List 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 by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: undetected deadlock in ALTER SUBSCRIPTION ... REFRESH PUBLICATION
Next
From: Amit Kapila
Date:
Subject: Re: undetected deadlock in ALTER SUBSCRIPTION ... REFRESH PUBLICATION