Hi, On November 19, 2021 12:31:00 PM PST, Tom Lane <t...@sss.pgh.pa.us> wrote: >Virender Singla <virender....@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 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.
