Re: TOAST - why separate visibility map

Hi,

On November 19, 2021 12:31:00 PM PST, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>Virender Singla <virender(dot)cse(at)gmail(dot)com> writes:
>> Why do Toast tables have it's own visibility map and xmin, xmax columns etc?
>> Isn't it increasing row size in a toast table and adding more complexity?

Given the size of toasted data, the overhead is unlikely to be a significant overhead. It's much more an issue for the main table, where narrow rows are common.

We don't want to use the main table visibility information for vacuuming either - that'd practically prevent HOT cleanup, and we'd a new expensive way of doing cleanup in toast tables using the main row's visibility information.

>There are advantages to having the same low-level format for toast tables
>as regular tables --- for example, that you can look into a toast table
>for debugging purposes with normal SQL queries. Even if we weren't tied
>to that format for disk-storage-compatibility reasons, I'd be disinclined
>to change it.
>
>It might be feasible to drop the visibility map for toast tables, though.
>I agree that's not buying much, since ordinary queries don't consult it.
>Not sure if there'd be a win proportional to the added code complexity.

I think it be a bad idea - the VM is used by vacuum to avoid rereading already vacuumed ranges. Loosing that for large toast tables would be bad.

Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.