Hi,
On November 19, 2021 12:31:00 PM PST, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Virender Singla <virender.cse@gmail.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
maintable, 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
toasttables would be bad.
Andres
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
