"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."
Completely agree, row size should not be a big concern for toast tables.
However write amplification will happen with vacuum freeze wh
Andres Freund writes:
> On November 19, 2021 12:31:00 PM PST, Tom Lane wrote:
>> It might be feasible to drop the visibility map for toast tables, though.
> 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 woul
Hi,
On November 19, 2021 12:31:00 PM PST, Tom Lane wrote:
>Virender Singla 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 unlike
Virender Singla 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?
There are advantages to having the same low-level format for toast tables
as regular tables --- for example, that you
Another point that currently manual VACUUM job does cleanup/freeze on
primary table first and then toast table. It looks easy pick to possibly
have a configurable parameter to run it on both the tables in parallel.
On Sat, Nov 20, 2021 at 12:15 AM Virender Singla
wrote:
> Why do Toast tables hav
